[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] [Issue 95] "wiredByImpl" is an invalid attributefor a Composite Reference
Thanks for outlining the difference between wiredByImpl and 0..0. Given this clarification, I'll withdraw my proposal to eliminate wiredByImpl (I guess this is why it was retained in OSOA). -Anish -- Simon Nash wrote: > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]