sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [sca-assembly] Issue 8 (was: Issue 17 proposal)
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Wed, 20 Feb 2008 12:10:16 +0000
Michael,
Hmm, I can't view the case of resolving
QNames in the including composite as anything other than an override.
You may be right to be wary, but I think
that this is inherent in this approach:
I suppose you could take the view that
someone building a composite designed for inclusion would deliberately
NOT provide artifacts in that contribution
which would resolve QNames found in that composite, IF the rule is
established that the including composite
provides the resolution, that is.
This feels unnatural. The most
obvious behaviour is to include the artifacts that provide the resolution
with the
included composite itself. Exporting
of the relevant artifacts is clearly required.
If this is done, then the including
composite seems to have a choice - use the artifacts provided along with
the
included artifact, or use some others
chosen by the including composite designer. This is where the question
of "override" comes from,
as a natural part of the including process.
Now, I can see that IF the designer
of the included composite so chooses, the composite and all its QName
references COULD be put into the same
namespace - so that importing the composite implies importing all
the other artifacts as well. Then,
an including composite must necessarily accept all the artifacts - however,
the current spec is at best vague about
what happens IF the including contribution DOES have its own artifacts
declaring things in the same namespace
as the included composite and what happens IF the artifacts clash
with the imported artifacts.
IF the referenced QNames in the included
composite are NOT in the same namespace as the included
composite, then all bets are off. The
including composite's contribution is NOT OBLIGED to import any
of the other namespaces and can thus
supply all of its own artifacts to resolve QName references made
by the included composite. In
this case, "override" is a breeze - it's automatic.
By contrast, always resolving the QNames
in the included composite's contribution makes override
impossible under any circumstances.
Maybe this is desirable, but it may limit reuse.
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
"Michael Rowley"
<mrowley@bea.com>
19/02/2008 19:58
|
To
| "Anish Karmarkar" <Anish.Karmarkar@oracle.com>,
Mike Edwards/UK/IBM@IBMGB
|
cc
| "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
|
Subject
| RE: [sca-assembly] Issue 8 (was: Issue
17 proposal) |
|
The problem with Mike E's description is that he talked about
_overrides_. I don't think that overrides for QName resolution have
been proposed by anyone yet, although perhaps we should consider it.
I think that Anish and I were arguing between resolving QNames in either
the including composite (his preference) or the included composite (my
preference).
If we went with an overriding scheme then things could get substantially
more complicated, at least to explain. The name resolution scheme
then
becomes an algorithm and the introduction of new names into the
environment can cause changes in the resolution of names in a way that
can be a pain to debug (reminiscent of classpath/classloader bugs).
That isn't to say I'd never support an approach that uses overrides, but
I must admit to being wary.
Michael
-----Original Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Tuesday, February 19, 2008 11:19 AM
To: Mike Edwards
Cc: OASIS Assembly
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
---------------------------------------------------------------------
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]