OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

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


Subject: Re: [sca-bindings] Document with proposed resolutions to JCA issues120, 121, 122, 123


Hi Simon,

Editorial nit - in at least one place you appear to have deleted the word "element" at the start of a description.  This construction appears in other places, and it probably should be consistent.

Hmm: BJC 20021 currently reads:
"For an SCA service with a binding.jca element with the @uri attribute value specified, if the resource is not present at the JNDI location identified by the @uri attribute or is not an Activation Spec the SCA runtime MUST raise an error"

If I'm interpreting this correctly, Demorgan's law suggests a rewrite: (!present || !activation spec) is equivalent to !(present && activation spec)

I think this is saying that the JNDI location must identify a resource, and that resource must be an Activation Spec.  I'd reword this as:
"For an SCA service with a binding.jca element with the @uri attribute value specified, if the JNDI location identified by the @uri attribute does not locate an Activation Spec, the SCA runtime MUST raise an error."

Likewise for BJC 20022, which reads:
"For an SCA reference with a binding.jca element with the @uri attribute value specified, if the resource is not present at the JNDI location identified by the @uri attribute or is not a Connection Factory the SCA runtime MUST raise an error"

I'd change this to:
"For an SCA reference with a binding.jca element with the @uri attribute value specified, if the JNDI location identified by the @uri attribute does not locate a Connection Factory, the SCA runtime MUST raise an error

Feels to me like the normative statements for BJC20026 & BJC20027 could (should?) be combined into one.  Instead of:
"The value of the outboundInteraction/operation/@name attribute MUST be unique within the ouboundInteraction element" and "The value of the outboundInteraction/operation/@name attribute MUST match the name of one of the operations in the containing service's or reference’s interface"

why not:
"For the value of the outboundInteraction/operation/@name attribute, if the value matches any other operation/@name attribute value under the same outboundInteraction element, or if the value does not correspond to the name of one of the operations in the interface for the containing service or reference, the SCA runtime MUST raise an error."

BJC20029 is appearing before the @type attribute, rather than after.

This is unrelated to Simon's changes: Is it just me, or does the normative statement JBC20016 not make sense?  It says if something does not exist, it must be interpreted as implementing MessageListener.  How can something that doesn't exist implement anything?

BJC20023 says: "The value of the inboundInteraction/inboundOperation/@name attribute MUST match the name of one of the operations in the containing service's or reference's interface".  Don't we want this to read:

"If the value of the inboundInteraction/inboundOperation/@name does not match the name of one of the operations in the interface from the containing service or reference, then the SCA runtime MUST raise an error."

-Eric.

On 03/10/2010 09:13 AM, Simon Holdsworth wrote:
OFD2683B32.CEB693A3-ON802576E2.005D935D-802576E2.005E1E39@uk.ibm.com" type="cite">
Folks,

In the interest of getting these issues closed as quickly as possible, I've produced an updated revision of the JCA binding spec that includes the proposed resolutions for these issues.

I did modify some of the specific resolution text from what's in JIRA, and also made some other minor changes around the normative statements which were not originally stated, so the changes in this document constitute the current proposed resolution for each of these issues.

I hope putting them all in one document does not confuse matters, I couldn't face making four separate documents.



Here's a PDF version, unfortunately again my PDF writer has chosen to mark a load of cross references as having been updated when there is actually no change to the text.  I have not changed any normative statements from BJC20001 to BJC20020; everything from BJC20021 onwards is new.



Regards, Simon

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair, AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com





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






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


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