Re: [sca-assembly] Issue 17 proposal

[Scott Vorthmann <scottv@tibco.com>]

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>