Re: [sca-assembly] Issue 17 proposal

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

+1
Using different NSs and ensuring that they are followed in a 
distributed/parallel dev environment does solve the problems.
It is also the responsibility of the includer to ensure that there isn't 
any problems/conflict especially when picking a composite from a 
different contribution.

-Anish
--

Mike Edwards wrote:
> 
> Anish,
> 
> This is a good discussion.  There are clearly 2 alternative choices here 
> and both have
> advantages and disadvantages.
> 
> I tend to favour your view that the including composite should take 
> precedence and that
> choices made by the included composite can in effect be overridden by 
> the including
> composite.  Without this, the including composite cannot control what is 
> going on and is
> at the mercy of the behaviour of the included material.
> 
> A concern I have about this is that the overriding could be 
> "accidental".  The override
> depends on the including composite "knowing" that the included composite 
> uses a
> particular namespace.  This could be equally true for any other type of 
> artifact, such as
> a Java package.
> 
> The overriding could lead to some clashes.  Including some composite 
> from a "remote"
> contribution, the XML namespace could get overridden so that, for 
> example, a WSDL
> used in the remote contribution ends up with its XSD references to types 
> being resolved
> in the including composite's contribution.  If the WSDL has been used in 
> the remote
> contribution to generate a Java interface used by implementation code in 
> that contribution,
> this could result in the WSDL used by the including contribution 
> actually clashing with
> the Java interface declaration used by the implementations, causing an 
> error.
> 
> The route to avoid these problems is to use cleanly separated namespaces 
> in each
> contribution.  This applies to XML artifacts and to non-XML artifacts.
> 
> 
> 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
> 
> 
> *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
> 
> 19/02/2008 05:19
> 
> 	
> To
> 	Michael Rowley <mrowley@bea.com>
> cc
> 	Scott Vorthmann <scottv@tibco.com>, OASIS Assembly 
> <sca-assembly@lists.oasis-open.org>
> Subject
> 	Re: [sca-assembly] Issue 17 proposal
> 
> 
> 	
> 
> 
> 
> 
> 
> 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
>  >
> 
> ---------------------------------------------------------------------
> 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
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> /
> /
> 
> /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/
> 
> 
> 
> 
> 
>