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

[David Booz <booz@us.ibm.com>]

:-) There's a reason it's called work.

1) Hmmmm....what was I thinking about? I clearly remember working on a statement that mentioned both, but that is clearly not POL30007 nor are there any in the vicinity of POL30007. I looked at 4.12 to see if there was a statement in there that I was basing my changes on. POL40018 is the statement that sums up section 4.12, but it doesn't mention bindingTypes explicitly, only policySets. I guess I made a leap to bindingType to cover the "provided" intents clause.
So, I'd like to find a way to link POL-TA-30007 and POL-TA-40027, since POL-TA-40027 captures more precisely what POL30007 is after. I think that's why I attempted to word POL-TA-30007 the way I did it....as a copy of POL-TA-40027 but with the profile intent twist added to it.

2) Ah, ok. The spec doesn't talk about policySets in the context of the implementation or structural hierarchy. This might be a hole in the spec. That leaves us with section 4.12 to see what happens; there is no guidance that I can see. 4.12 only talks about direct and external attachment. Section 4.8 (which contains the normative statement in question) is titled "Intents on interfaces", but does also talk about policySets attached to an interface. Effectively, I think POL40016 is trying to assert something that is not stated in 4.12, namely that policySets attached to interfaces should be logically attached to the owning service or reference such that the policySets apply to any child bindings. We might be better off trying to fit policySets in the structural and implementation hierarchy model in order to bring more clarity. What do you think? Now, to answer your question; if there are policySets already attached to the reference then I think the spec should say that policySets from the interface should be merged (union) in. If you want an override semantic, the only one that makes sense to me is that policySets attached to an <interface/> element override what's in the interface definition itself.

3) Yeah, I thought that might have been your reason. You made similar changes in other places which I think were good changes. But in this instance it seemed important to cover the composite to componentType behavior for interface attachment because it is not handled anywhere else. Most notably, I don't think this case is covered by the structural/implementation hierarchy TAs, and I think it is so subtle that it deserves explicit treatment.

4) Ok, this is going to get interesting. Perhaps an example will help. Component A is implemented by implementation I. I exposes a service S with interface X. Component A has service S from the componentType of I. Where is the interface element, under A-S or in the componentType of I? I couldn't tell from you words if the attachment point for the intent was in the componentType or in the component. I guessed it was the former since that's what POL40019 is talking about. Using my example; in Java the intent attachment would be in the Java interface definition pointed to by the @service annotation in the implementation. However, your response below suggests that you were thinking that the interface element where the intent was attached was in the component? Maybe we need both.

5) Ok, I did debate this with myself. This is one of the points where I stopped and took a break to think. I opted to be concrete for the benefit of the testcase writer, something you've advocated in the past :-). Maybe this is too concrete, but I tried to use vague words so that the mechanism could be up to the testcase writer. I want it to be possible for the failure to be anywhere between the two SCA runtimes. One of the things I wondered about is the variability in prospective SCA runtimes such that vendors may need their own testcase for this depending on how they've built their runtime. Most of us are probably thinking of using webservice reliable messaging, but that might not always be the case. What I didn't want to do was write the TA such that a runtime could pass the tests without actually implementing reliable messaging. I think that's what would happen if we removed (b) from the TA. The only reason the concept of reliable messaging exists is because comm errors do happen once in a while. In the end, it may not be possible to write a test for this, but I'd still prefer to have a more concrete TA.

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/14/2009 03:47:35 PM---Dave, Responses inline as <mje> </mje>

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

---

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