Re: [sca-policy] Proposed updates to the TA document - another pass....

[Mike Edwards <mike_edwards@uk.ibm.com>]

Dave,

Responses inline as <mje>
</mje>

are we having fun yet ??


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:	14/07/2009 19:18
Subject:	Re: [sca-policy] Proposed updates to the TA document - another pass....

---

Hi Mike,

1) POL-TA-30007: POL30007 mentions intents satisfied by policySets and
bindingTypes which is why I added words to that effect. Can you help me
understand why you removed my changes? 
<mje>
Here is POL30007 straight from the PR version
of the spec:
"If
a profile intent is attached to an artifact, all the intents listed in
its @requires attribute MUST be satisfied as described in section 4.12.
[POL30007]"

Where does it talk about policySets and bindingTypes?
"satisfied" is understood as a
term explained by 4.12 (logically this should be a reference to another
TA which deals with the
normative aspects of "satisfied")
- but I think a test writer can make sense of the TA as I've written it.
</mje>

2) POL-TA-40025: you made a comment but I didn't understand the question.
POL40016 is talking about how policySets and intents from interfaces and
interface elements play into the rules of where they are applied. POL40016
is not talking about policySets and intents which are attached directly
to the reference.
<mje>
My cryptic comment was asking whether a policySet
applied to the <reference/> element overrides any policySet
attached to the <interface/> element
or to the interface document.  In other cases of this kind, policySets
ARE 
overridable.  This is really a spec
question, not a TA question.
</mje>

3) POL-TA-40024 and POL-TA-40025: I changed the target to composite or
component service (and reference respectively), you removed the composite.
Why? I don't see anything in POL40016 that restricts the statement to component
services and references.
<mje>
I reasoned it like this - only component
services actually get exposed in a way that is directly testable.
The way that a composite service affects
things is by its effect on the componentType of the implementation.composite,
which in turn affects the behaviour of the
component service using that composite.  I believe that there are
other
places that deal with the link from the composite
service to the componentType and so there is no need to state
anything here about composite services (ditto
for references), since there is no conceivable testcase that ain't
better done elsewhere.
</mje>

4) Thanks for adding the TAs for POL40019, but I'm finding the words to
be hard to parse. Could we re-word the first pre-req: a) <component/>
has an <implementation/> which exposes a <service/> that has
an <interface/> attached to it. Same comment (with adjustments for
reference) on the other TA for POL40019.
<mje>
I'm OK with rewording this - my English is
nothing to write home about (said as a true Welshman  ;-) )
However, your words here miss one important
item - "corresponding <service/>" - which can also  be
expressed as the
"<service/> with the same name
as the <component/><service/>"
</mje>

5) POL-TA-80001: you made a comment, are you referring to the whole (b)
prereq or just the end of it?
<mje>
It's a comment about b) - and it applies
to POL-TA-80002 as well.  I don't think it matters whether there is
a failure of comms or not.
Under *any* circumstances, "at least
one", "at most one", "only one" message must be
delivered.
Of course, trying to create a circumstance
where the wrong number of deliveries will have a chance of occurring is
going to tax
the testcase writer in the extreme - maybe
we need to have a little chat with our messaging buddies to find out how
they go about
building tests for this kind of situation
 ;-)
</mje>

General comment: much of what you've done seems stylistic/editorial
in nature where there are a number of different ways to word these things.
I don't feel strongly about any particular style of expressing these TAs,
so I'm fine with your changes, with the exceptions noted above.
My general approach has been to lay out
the TAs in a way that naturally leads into the testcases - "you're
concerned with an X with characteristics Y - and these other things Z need
to be set up ahead of time - and if so, the following M must be true".
 The more concrete they are, the better.

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 ---07/13/2009 10:43:20 AM---Dave, You inspired me. Here is my pass
over your version of the document, fully

From:	Mike Edwards <mike_edwards@uk.ibm.com>
To:	sca-policy@lists.oasis-open.org
Date:	07/13/2009 10:43 AM
Subject:	Re: [sca-policy] Proposed updates to the TA document - another pass....

---

Dave, 

You inspired me. Here is my pass over your version of the document, fully
change marked... 




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:	12/07/2009 02:31
Subject:	[sca-policy] Proposed updates to the TA document

---

I spent a lot of time reviewing this document and have come up with the
following proposed changes. Please review closely. I tried to bring some
consistency to the approach for the TAs, but may have missed some places
as I did this work in about 7 different sessions, so my continuity may
not have been great.

thanks in advance for reviewing

(See attached file: SCA-Policy-1.1-Test-Assertions-WD-01_dab11July2009.doc)

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[attachment "SCA-Policy-1.1-Test-Assertions-WD-01_dab11July2009.doc"
deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
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

(See attached file: SCA-Policy-1.1-Test-Assertions-WD-01_dab11July2009_mje.doc)---------------------------------------------------------------------
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  [attachment "SCA-Policy-1.1-Test-Assertions-WD-01_dab11July2009_mje.doc" deleted by Mike Edwards/UK/IBM] ---------------------------------------------------------------------
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