RE: [sca-policy] Revised Test Assertions Document

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

All,
    sorry for the delay - I've rewritten the Test Assertions for [POL30002]
through [POL30023] as per my AI. See "PolicyTests-EJW.doc" attached. I based
this on the document Ashok posted to the list on Thursday so it includes all
the work he did up to that point. I also turned on change tracking but it's
probably easier to read without the changes.

I couldn't figure out how to write [POL30001] and [POL30024] but I think the
rest s/b OK. I've included some notes below for clarification that the TC
may want to discuss.

Also noticed a formatting error on Lines 422 - 423 of
"sca-policy-1.1-spec-cd02" PRD Word document. The line has been
inadvertently split and needs the bullet to align with list of other
attributes. This can probably be fixed editorially.


Best Regards,
              Eric.
Eric Wells.
Consulting Engineer.
Hitachi Computer Products (America) Inc.
San Francisco, CA. USA.
+1 (415) 656-4346
eric.wells@hitachisoftware.com



-----Original Message-----
From: ashok malhotra [mailto:ashok.malhotra@oracle.com] 
Sent: Thursday, March 26, 2009 4:02 PM
To: OASIS Policy
Subject: [sca-policy] Revised Test Assertions Document

I did some work on assertions 30022 thru 400026.
When Eric sends his comments on 30001 thru 30021 I will splice them into
this document.
--
All the best, Ashok



Notes on Policy Test Assertions [POL30001] to [POL30024]
========================================================
[POL30001]
Not sure what the concrete target and prerequisites for this should be.

[POL30004]
What happens if there is only one <qualifier> element and it does not set
the @default attribute? (Or if it explicitly set the value to "false") In
this case there is no default qualifier - see [POL30022] below.

[POL30007]
This requires the "PolicySet Matching Algorithm" in Section 4.12.
May be covered by [POL40018]

[POL30008]
Lines 534 - 535 "... an unqualified intent that is listed within the
@provides attribute value of the parent policySet element." Doesn't this
imply that the <policySet> @provides attribute must list the unqualified
form as well as the qualified form? However the examples contradict this
interpretation.
Would a better wording be:

If a policySet element contains intentMap child elements, the value of the
@provides attribute of each intentMap MUST correspond to the unqualified
form of an intent that is listed within the @provides attribute of the
parent policySet element. [POL30008]

[POL30010]
Not sure if the target should be the entire @provides list or just qualified
intents in that list.
Similarly, not sure if the prerequisite is "@provides contains qualified
intents" or just plain intents.

[POL30008], [POL30010], [POL30020}
Taken together these seem to be a complicated way of saying "each intentMap
within a given policySet MUST uniquely provide for a specific intent". (As
stated on lines 543 544) Could these statements be simplified/reworded?

[POL30011]
Doesn't this wording imply that the wsp:policyAttachment children or
policies using extension elements have to satisfy all the intent in the
@provides list of the <policySet>? Should this statement be of the same form
as [POL30008] & [POL30010]? I.E. each child element MUST satisfy exactly one
(at most one?) intent listed in the @provides attribute of the parent
<policySet>.

[POL30013]
Not sure how to include qualified intents.

[POL30017]
Should this be defined in terms of the QName (as specified) or the @name
attribute?

[POL30018]
Should this test that the @appliesTo XPath expr identifies "one or more SCA
constructs this policySet can configure"?

[POL30019]
Should this test that the @attachTo XPath expr identifies "one or more
elements in the Domain"?

[POL30020]
Schema seems to allow nesting <intentMap> elements if qualified, but not
sure how this should be handled.

[POL30021]
Schema seems to allow nesting of <intentMap> elements (if qualified).
Not sure if @provides of an <intentMap> should include @provides of any
nested <intentMap> elements.
(If so then [POL30021] needs rewording - If not then do we need to make any
normative statements?)
Do we really want the value of the @provides attribute INCLUDED? As opposed
to all intents listed in the @provides attribute. Could inclusion lead to
duplicate intents in the parent @provides attribute? If so would this be a
problem?

[POL30022]
There is a case where there may be no default <qualifier> element.
I don't think this is covered by [POL30020] as that refers to <policySet>
and <intentMap> elements.
This statement covers the default <qualifier> element of <intent> elements.
However it may be that [POL30020] (and other statements) covers this
implicitly.

[POL30023]
Not sure what the concrete target and prerequisites for this should be.
Does this apply to ANY two associated intents? E.G. Is it allowed to list
two (or more) mutually exclusive events in the @provides attribute of a
<policySet> element? Sorry if this seems a stupid question but could not the
"PolicySet Matching Algorithm" in Section 4.12 eliminate all but one of the
mutually exclusive intents resulting in no conflict? (Also section 4.5
"Usage of @requires attribute for specifying intents") I can't figure out
all the ramifications for this one!

[POL30024]
Not sure how this assertion can be written - can we define "test"
<policySet> elements that use each of the intents defined in appendix B and
check the SCA runtime accepts these?

PolicyTests-EJW.doc