Re: [sca-assembly] [ASSEMBLY-88] Possible duplicate functionalityoffered by constrainingType and component - proposed resolution

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Mike Edwards wrote:
> 
> This is a proposal to resolve Issue 88.
> 
> Summary:
> - remove constrainingType from the specification
> - add an attribute to <component/> called @constrained which is a 
> boolean value with a default of "false"
> 
> - a <component/> with constrained=false is just like a component today - 
> no changes
> - a <component/> with constrained=true requires its implementation to 
> follow rules similar to those for
>   constrainingType - namely:
> 
> "When the component using an implementation has @constrained=true the 
> implementation's component type
> MUST contain all the services, references and properties explicitly 
> declared by the component. The component’s
> references and services can have interfaces specified and can have 
> intents specified - the implementation's
> service interfaces must be the same or a superset and its reference 
> interfaces must the the same or a subset, while
> any intents present in the componentType must match those declared by 
> the component.. An implementation MAY
> contain additional services, additional optional references 
> (multiplicity 0..1 or 0..n) and additional optional properties
> beyond those declared by the component, but MUST NOT contain additional 
> non-optional references
> (multiplicity 1..1 or 1..n) or additional non-optional properties (a 
> property with mustSupply=true). (and any such references
> will not be wired and any such properties will not be configured by the 
> component). Any services in the componentType
> which are not also declared by the component cannot be wired or promoted"
> 

Other than the inability to promote or be a source/target in a wire 
element, what other restriction does this add? What is stated here is 
already true regardless of constrainted='true'. For example, the 
implementation cannot contain non-optional properties that are not set 
in the component configuration. This is already true (although we state 
this in the opposite way: a component must set the value for a required 
property).

> I believe that this allows a component to control what its 
> implementations MUST look like, which is the idea behind
> constrainingType.

I'll respond to the idea behind constrainingType in a reply to your 
other email. I don't think this captures it.

-Anish
--

> 
> Detailed changes:
> 
> 
> 
> 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