OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue 17 proposal


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]