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

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Eric,

Thanks for the comments, please see
my responses below.  Here's an updated document.



This time the PDF writer did not mark
every cross reference in the document as being updated - software will
never cease to amaze me...

Just to be clear on the changes in the
doc regarding each issue (based on the pdf version of the document):

BINDINGS-120:  lines 115-120 (values
for @uri attribute)

BINDINGS-121:  lines 99 and 571
(change attribute name), 287-302 (inboundOperation element changes except
@type normative statement), 330-341 (operationSelector changes)

BINDINGS-122:  lines 223-227 (priority
of operation vs binding), 239-241 (conditions on the @name attribute)

BINDINGS-123:  All normative statements
relating to the @type attribute

Editorial - minor updates to wording
of attribute/element descriptions, fixed ToC.

Regards, Simon

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

Eric Johnson <eric@tibco.com> wrote on 11/03/2010
02:31:00:

> 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.
 
OK, I guess I just changed things I saw around the
places I was editing; I'll change the rest to 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."

I don't feel strongly either way, we have plenty of
other examples like this.  I wanted to retain the form if true condition
then SCA runtime MUST raise an error, which requires the (!A || !B) form,
but I'm OK with "does not locate an Activation Spec".  I've
changed this in the revision.
 
> 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

As above.  I've changed this in the revision.

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

Just wanted to keep separate error conditions separate.
 I don't mind combining them, although this statement does not apply
to the SCA runtime, it applies to the validity of the binding.jca element,
so its not the SCA runtime raising the error.  How about:

"The value of the outboundInteraction/operation/@name
attribute MUST be unique within the outboundInteraction element and MUST
match one of the operations in the containing service's or reference's
interface"

There are precedents in the assembly spec for statements
with more than one MUST in them, not really sure that the second one is
needed.

I've changed this in the revision.
 
> BJC20029 is appearing before the @type attribute, rather than after.

OK. I've changed this in the revision.

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

I think what this is trying to say is that if the
element is not specified, then the default listener type is the standard
JCA listener interface and nothing additional can be assumed by the runtime.

Perhaps the statement would be better worded:

If the inboundInteraction/listener element is not
specified, the SCA runtime MUST use the default javax.resource.cci.MessageListener
interface from the JCA specification [BJC20016].

I've changed this in the revision as part of the resolution
to issue BINDINGS-121
 
> 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 raisean
error."

No, because this describes an error with the binding.jca
element and relates to the correctness of the document, not validated by
the runtime (same as for BJC20026)

I have not changed this in the revision.

> -Eric.
> 
> On 03/10/2010 09:13 AM, Simon Holdsworth wrote: 
> 
> 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

---

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

sca-jcabinding-1.1-spec-cd03-rev3-issues120+121+122+123-rev1.doc

sca-jcabinding-1.1-spec-cd03-rev3-issues120+121+122+123-rev1.pdf