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: Re: [sca-assembly] Issue 17 proposal


It seems that the differences in opinion are over how to handle the
presence of conflicts across contributions.  Is the including contribution
always searched for or never searched at all?  Reminds me of JEE class
loaders.  I like Anish's approach but suspect that vendors will have to
provide a mode which reverses the resolution order, just like in JEE.


Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome


                                                                           
             Anish Karmarkar                                               
             <Anish.Karmarkar@                                             
             oracle.com>                                                To 
                                       Mike Edwards                        
             02/19/2008 11:19          <mike_edwards@uk.ibm.com>           
             AM                                                         cc 
                                       OASIS Assembly                      
                                       <sca-assembly@lists.oasis-open.org> 
                                                                   Subject 
                                       Re: [sca-assembly] Issue 17         
                                       proposal                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




+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/
>
>
>
>
>
>

---------------------------------------------------------------------
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





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