Re: [sca-assembly] [Issue 95] "wiredByImpl" is an invalid attribute for aComposite Reference

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

Another way to go here is to consider that the act of promotion is a conscious act of creating public visibility for the purposes of configuration. In this sense, promotion as a concept is incompatible with wiredByImpl which clearly wants the wiring configuration to be managed by the component implementation. Therefore, we could decide that wiredByImpl + promotion is an error. I don't recall, did we discuss this on the call? Perhaps we did and too much of Mom's cooking has dulled my memory.

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

Simon Nash ---11/30/2008 07:01:35 PM---Anish, I agree with your comments about the meaning of wiredByImpl on a

From:	Simon Nash <oasis@cjnash.com>
To:	OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:	11/30/2008 07:01 PM
Subject:	Re: [sca-assembly] [Issue 95] "wiredByImpl" is an invalid attribute for a Composite Reference

---

Anish,
I agree with your comments about the meaning of wiredByImpl on a
composite reference.  This is the point I was trying to make
(albeit not very successfully) on the call.

Regarding 0..0, I don't think this is the same as wiredByImpl.
I think a wiredByImpl reference could be 0..1, 1..1, 0..n or 1..n.

If it is 1..n or 0..n, it's represented by an array in a Java
component implementation; otherwise it's represented by a scalar.

If it is 0..1 or 0..n, the implementation is allowed to wire it but
is not obliged to do so; otherwise, the implementation must wire it.

   Simon

Anish Karmarkar wrote:
> Mike,
> 
> Apologies for misunderstanding your proposal on the call today. 
> Unfortunately, line numbers on a 2007 .doc file don't mean a whole lot 
> to me.
> 
> IIUIC, what you are proposing is to get rid of the attribute wiredByImpl 
> on a composite reference, while retaining the ability to promote a 
> component reference that has wiredByImpl='true'.
> 
> If this is correct, I think this is problematic. Without the 
> wiredByImpl='true', the componentType associated with the composite will 
> not contain information about the fact that the reference cannot be 
> wired. Higher-level composites won't know the cardinality associated 
> with the reference (which is 0..0) and therefore will be free to wire 
> it. Unless, the spec says that wiredByImpl='true' automatically becomes 
> part of the CT associated with the composite by the virtue of the fact 
> that the underlying component reference has wiredByImpl='true'. We allow 
> narrowing of constraints when promoting. A 0..0 cannot be narrowed any 
> further, so wireByImpl='true' is indeed ripe for defaulting in such cases.
> 
> But as it stands I don't think there is any inconsistency in the spec 
> (other than the fact that it does not say that you cannot change the 
> value of wiredByImpl when promoting).
> 
> Currently, wiredByImpl says:
> "wiredByImpl : boolean (0..1) - a boolean value, "false" by default, 
> which indicates that the implementation wires this reference 
> dynamically.  If set to "true" it indicates that the target of the 
> reference is set at runtime by the implementation code (eg by the code 
> obtaining an endpoint reference by some means and setting this as the 
> target of the reference through the use of programming interfaces 
> defined by the relevant Client and Implementation specification).  If 
> "true" is set, then the reference should not be wired statically within 
> a composite, but left unwired."
> 
> Which seems right to me. There is implementation code associated with a 
> composite reference: it is the code associated with the corresponding 
> promoted component reference (however levels deep).
> 
> OTOH, the existence of wiredByImpl when we already have the multiplicity 
> attribute (on both component reference as well as composite reference) 
> always seemed a little strange to me. wiredByImpl is really saying 
> multiplicity of 0..0, why not then just say exactly that. I know this 
> was discussed during the OSOA days, but I don't recall why addition of a 
> new attribute was chosen over 0..0.
> 
> I'll be bold and make a proposal to remove wiredByImpl altogether and 
> use 0..0 on the multiplicity attribute instead (with the usual narrowing 
> rules for promotion).
> 
> I'm hoping that, if there was a good argument for choosing wiredByImpl 
> over 0..0 in OSOA, someone will bring it up here.
> 
> Comments?
> 
> -Anish
> -- 
> 
> Mike Edwards wrote:
>>
>> Raiser:                Mike Edwards
>>
>> Target:                Assembly spec: sca-assembly-1.1-spec-cd01-rev3.doc
>>
>> Description:
>>
>> The current spec has the attribute @wiredByImpl as an attribute of a 
>> Composite reference element.
>> This cannot be valid, since there @wiredByImpl=true implies that the 
>> composite itself will act to wire
>> the reference at runtime.  However, this can never happen since there 
>> is no active code in the
>> composite which could do this.
>>
>> It is valid for a reference on a component within the composite to 
>> have @wiredByImpl on one of its
>> references, but this applies to wiring of the component reference - 
>> and NOT to wiring of any
>> promotion of that reference.
>>
>> Proposal:
>>
>> Remove @wiredByImpl from <reference/> within a <composite/>.
>>
>> Specifically:
>>
>> Line 1337 - remove  wiredByImpl="xs:boolean"?
>>
>> Lines 1399 - 1405 - remove
>>
>> Lines 3825 - 3826 - remove
>>
>> Lines 3971 - 4006 - replace with:
>>
>>     <complexType name="ComponentReference">
>>
>>             <complexContent>
>>
>>                             <sequence>
>>
>>                                     <element ref="sca:interface" 
>> minOccurs="0" maxOccurs="1" />
>>
>>                                     <element name="operation" 
>> type="sca:Operation" minOccurs="0"
>>
>>                                             maxOccurs="unbounded" />
>>
>>                                     <element ref="sca:binding" />
>>
>>                                     <element ref="sca:callback" 
>> minOccurs="0" maxOccurs="1" />
>>
>>                                     <any namespace="##other" 
>> processContents="lax" minOccurs="0"
>>
>>                                             maxOccurs="unbounded" />
>>
>>                             </sequence>
>>
>>                             <attribute name="name" type="NCName" 
>> use="required" />
>>
>>                   <attribute name="autowire" type="boolean" 
>> use="optional" />
>>
>>                             <attribute name="wiredByImpl" 
>> type="boolean" use="optional"
>>
>>                         default="false"/>
>>
>>                             <attribute name="target" 
>> type="sca:listOfAnyURIs" use="optional"/>
>>
>>                             <attribute name="multiplicity" 
>> type="sca:Multiplicity"
>>
>>                                     use="optional" default="1..1" />
>>
>>                             <attribute name="requires" 
>> type="sca:listOfQNames" use="optional"/>
>>
>>                         <attribute name="policySets" 
>> type="sca:listOfQNames"
>>
>>                                 use="optional"/>
>>
>>                             <anyAttribute namespace="##other" 
>> processContents="lax" />
>>
>>             </complexContent>
>>
>>     </complexType>
>>
>>
>> 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
>>
>>
>> ------------------------------------------------------------------------
>>
>> /
>> /
>>
>> /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
> 
> 



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