Re: [sca-assembly] Issue 17 proposal

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

I missed the other half. Thanks for pointing that out. For some reason I 
thought issue 24 [1] dealt with that. AFAICT, 17 and 24 are the same.

SCA does not define a component model a la WSDL 2.0. All we have is 
Infoset. Not sure what you were thinking wrt to a formal proposal. I 
would be interested in seeing it. Wrt Qname resolution, my inclination 
is to say that all the resolutions happen in the context of the 
including composite. When u do an include there is no encapsulation, 
everything belongs to the including composite. The including composite 
defines the scope (property names, target names etc -- target names in 
either composite can freely mix service names from both composites) and 
the resolution mechanism. IOW, given a composite that contains one or 
more sca:include elements, there exists an equivalent composite without 
any sca:include elements whose characteristics are exactly the same. The 
rules in my proposal are for mapping a composite with include elements 
to one without.

Given that we don't have a formal component model a la WSDL 2.0, maybe 
equivalence rules is how we should state it in the spec.

Comments?

-Anish
--

[1] http://www.osoa.org/jira/browse/ASSEMBLY-24

Scott Vorthmann wrote:
> Anish,
> 
> I think the proposal as you've laid it out is reasonably sound, but I 
> think it addresses only half of issue 17 as captured.  I don't see 
> anything in your proposal to define when QNames, etc. are resolved.  (I 
> regard this as the thornier half of 17.)  Further, since your proposal 
> defines include at something like an XML Infoset level, it almost 
> exacerbates the QName problem... how would you require that "QNames have 
> already been resolved" if include is happening at this low level?
> 
> My suggestion is that we need to define include at the level of naming, 
> not at the level of XML.  In essence, we'd be saying that wire elements 
> (including those implied by "target=") in either composite can freely 
> mix component/service names from either composite.  Something similar 
> would be required for property names.  This achieves the goal of 
> include, and makes the XML issues moot.  I'd be happy to make a more 
> formal proposal along these lines, but perhaps we could have a little 
> discussion first.
> 
> Scott
> 
> On Feb 5, 2008, at 12:31 AM, Anish Karmarkar wrote:
> 
>> I took an action to provide a proposal to resolve issue 17 [1]. Here 
>> it is.
>>
>> The proposal in this email was discussed as an errata for SCA 1.0 in
>> OSOA, but it was decided that it resulted in too much change to be
>> considered an errata and therefore not implemented. The proposal below
>> was worked on by several folks in OSOA including Henning Bloom, Dave
>> Booz, Scott Vorthmann (hope I didn't miss anyone). But it should not be
>> construed that they agree with all the aspects of this proposal.
>>
>> I. Current problems with the spec:
>>
>> 1) inclusion is not defined recursively. I.e., it does not say what is
>> supposed to happen if an included composite contains an include (which
>> the spec says is allowed).
>> 2) It is defined as a textual include, which it most certainly isn't.
>> 3) Attributes (namespace decl, 'local' etc) on the included composite
>> are completely ignored.
>> 4) The current wording also says (through an example) that the composite
>> resulting from the inclusion must be complete. This isn't true if there
>> is recursive inclusion. Only a deployable composite needs to be complete.
>>
>> II. Proposal:
>>
>> 1) Attributes 'targetNamespace', 'name', 'constrainingType' and 'local'
>> on the included composite are thrown away. For constraints on 'local'
>> see #4 below.
>> Rationale: composite inclusion results in losing the
>> encapsulation/scoping. Element children of the included composite are
>> now part of the including composite and are scoped to the the including
>> composite. Therefore, the attributes 'targetNamespace' and 'name' of the
>> included composite have no relevance.
>> 2) All NS decl on the included composite are inherited by the each of
>> the child elements of the included composite if they are inscope (not
>> overridden).
>> Rationale: Element and attributes are (and can be) of type xs:QName.
>> This requires inscope NS decl/binding.
>> 3) Attribute 'autowire', if specified on the included composite, is
>> included on all containing component elements unless the containing
>> component already specifies that attribute.
>> Rationale: By sticking autowire on the composite it is inherited by the
>> contained composites. It is a nice short cut. The intention of the
>> creator of the composite is to autowire the components, therefore this
>> should be retained on inclusion.
>> 4) If the included composite has the value 'true' for the attribute
>> 'local' then the including composite must have the same value for the
>> 'local' attribute. If not, that is considered an error.
>> Rationale: This is based on the assertion that local="true" is a
>> constraint, and that constraints must not be arbitrarily removed.
>> Components which are not required to be collocated, can be collocated,
>> where as the converse is not necessarily true.
>> 5) Attributes 'requires' and 'policySet', if present on the included
>> composite, are "merged" with corresponding attribute on the containing
>> component, service and reference elements. "merge" here means a set 
>> union.
>> Rationale: since they are constraints that must not be overridden, they
>> are merged.
>> 6) Extension attribute ,if present on the included composite, must
>> follow the rules defined for that extension. Authors of attribute
>> extensions on the composite element must define rules for inclusion.
>> Rationale: depending on the extension, there may be various ways to deal
>> with attribute extensibility. It does not seem right to define a one
>> size fits all. Perhaps a default behavior may be appropriate.
>>
>> III. Note
>>
>> This proposal does *not* address the issue of xml:base occurring on the
>> <composite> element of the included composite. I think it is important,
>> but given the fact that artifacts in SCA (composites, bindings etc) are
>> identified by QNames, this is less of a problem.
>>
>> IV. Wording changes:
>>
>> Word document with change bars for relevant parts of section 6.6 (WD02)
>> attached. Note that I have not modified/added examples to demonstrate
>> the changes. We might want to add additional examples to illustrate the
>> changes.
>>
>> Comments?
>>
>> -Anish
>> -- 
>>
>> [1] http://www.osoa.org/jira/browse/ASSEMBLY-17
>> <assembly-issue-17-proposal.doc><ATT8019818.txt>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php