Re: [sca-assembly] [ASSEMBLY 127] Need definition of compatible forproperty types - Proposal

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

I agree with the conclusion.

But since we are discussing this, I do want to make one point:

I think the rationale that SCA allows for the subtyping of interfaces at 
various places and therefore it should allow the same for properties is 
not right IMHO. Interfaces are contracts that are exposed so that 
services/references can be wired or promoted with the appropriate 
methods/types. For example, I can reduce the number of methods when 
promoting a service or change from interface.java to interface.wsdl. 
Component and composite properties exist to configure the 
implementation, not to expose the implementation property in a different 
way to some other entity (that is why there is no such thing as a 
property promotion). IOW, component property elements exist only to 
specify a value (either directly or via indirection). Subsetting the 
type of the property doesn't make any sense to me.
For example, lets say that the type of the property in the CT is 
xs:string. Let's say that the component configuration were to set the 
type to xs:int while it specifies the value of '1'. The value space of 
xs:int is a subset of xs:string, so it is a subtype, but I don't know 
what it would mean to call it a xs:int when the CT is going to treat it 
as a xs:string. The property cannot be promoted, i.e., no one is going 
to treat the property as a xs:int.

WRT to the proposal, we do need to say what compatibility means when a 
component property is set using "$". This is the only place where I can 
see that compatibility can mean subsetting the value-space. Eg., 
allowing a component property of type xs:string to point to a composite 
property value (using "$") of type xs:int.

-Anish
--

Mike Edwards wrote:
> 
> Discussion:
> 
> We discussed this a bit on the last Assembly call, but I'll try to 
> summarize it here.
> 
> We could choose to define "compatible property types" in a similar way 
> that we define "compatible interfaces" and
> this could lead us to define "compatible superset" and "compatible 
> subset" for property types.
> 
> However, for property types this seems pretty heavy.
> 
> A simpler approach is to say that the property types of two SCDL 
> elements must be "compatible", pure and simple,
> where in XSD terms this means that they have the same XSD type.  Where 
> one type is declared using a language
> other than XSD, say Java, then the appropriate C&I spec must define the 
> mapping rules of that type to XSD.  So, for
> Java this might be the JAXB rules.
> 
> So this would then apply to all cases where pairs of SCDL elements deal 
> with property types:
> 
> <component/> <property/> and <componentType/> <property/>
> <composite/> <property/> and <component/> <property/> (@source attribute)
> <componentType/> <property/> and <composite/> <property/> (when 
> computing the componentType of a composite)
> 
> Proposal:
> 
> Add a new subsection following section "4.4 Property":
> 
> 4.4.1 Property Type Compatibility
> 
> There are a number of places where the declared type of a property 
> element must be matched with the declared type of
> another property element.  These places include:
> 
> o Where a component <property/> sets a value for a property of an 
> implementation, as declared in the componentType of the implementation
> o Where a component <property/> gets is value from the value of a 
> composite <property/> by means of its @source attribute
> o Where the componentType of a composite used as an implementation is 
> calculated and componentType <property/> elements are
> created for each composite <property/>
> 
> In these cases, the types declared for the two <property/> elements MUST 
> be compatible. [ASM50038]
> 
> Compatible here means that the two types have to be the same XSD type 
> (where declared as XSD types) or the same XSD global element
> (where declared as XSD global elements).  For cases where the type of a 
> property is declared using a different type system (eg Java), then the
> type of the property is mapped to XSD using the mapping rules defined by 
> the appropriate implementation type specification
> 
> 
> 
> 
> 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/
> 
> 
> 
> 
> 
>