Re: [sca-assembly] Issue 17 proposal

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

I come to the exact opposite conclusion.

An included composite should not circumvent the resolution mechanism of 
the including composite (scoped to the contribution of the including 
composite + imports). I also do not see this different from the scenario 
where a <implementation.composite> points to a composite QName. Where do 
the dependent composite/artifacts, if any, get pulled from? Similarly, 
in an include element all we do is point to the composite QName. This 
QName is resolved per the usual resolution rules (existing contribution 
+ imports). Once the composite QName is resolved, there may be other 
artifact NS (similar to the scenario of implementation.composite) such 
as additional composites, java class files WSDL/Schema etc that need to 
be resolved. I believe this should follow the same rules for resolution 
as before. This, in fact, makes a lot more sense for <include> as there 
is no encapsulation (unlike that of implementation.composite) for include.

Come to think of it, this kind of situation appears all the time: wsdl 
has imports/includes, schema has imports/includes. If I get a wsdl from 
a 'foreign' contribution and that WSDL has an import of a well-known 
WSDL, and I happen to have that well-know WSDL in my 'home' 
contribution, I would most definitely want to use the one in my 'home' 
contribution. Not the one from the 'foreign' contribution as I have no 
guarantee that it is not changed.

Comments?

-Anish
--

Michael Rowley wrote:
> I assume that the QName resolution issue comes up when the including
> composite and the included composite are in different contributions.  I
> suspect that the semantics that users would prefer would be for QNames
> to be resolved in the context of the contribution of the _included_
> composite.  
> 
> This way the contribution of the included composite could contain that
> composite and all of its related artifacts.  The contribution of the
> including composite would only need to import the namespace of the
> composite that it includes.
> 
> [Sentences including "included" and "including" get very convoluted
> :-(.]
> 
> Michael
> 
> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: Tuesday, February 05, 2008 3:52 PM
> To: Scott Vorthmann
> Cc: OASIS Assembly
> Subject: Re: [sca-assembly] Issue 17 proposal
> 
> 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
> 
> ---------------------------------------------------------------------
> 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 
>