← Prev in month
← Prev in thread
RE: [sca-assembly] Issue 8 (was: Issue 17 proposal)
Mike,
You wrote:
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.
Yes, I believe that this is one of those
places where the model can get significantly simpler at the expense of a feature
that people conceivably might want.
However, there is a work-around for what I
believe is already a fairly uncommon case. Assume you want to reuse an
artifact (say “foo”) from some installed contribution, but you don’t
like the way that foo’s installed contribution resolved some of the
dependencies. You can always re-install foo’s contribution (creating a
new installed contribution) with a different set of dependency resolutions and
then reuse that.
If you don’t believe that, then I’ll
fall back on the first answer: the simplification makes it worth giving up the
capability.
Michael
From: Mike
Edwards [mailto:]
Sent: Wednesday, February 20, 2008
7:10 AM
To: OASIS Assembly
Subject: RE: [sca-assembly] Issue
8 (was: Issue 17 proposal)
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:
"Michael Rowley"
<>
19/02/2008 19:58
To
"Anish Karmarkar"
<>, Mike Edwards/UK/IBM@IBMGB
cc
"OASIS Assembly"
<>
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:]
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:
>
>
> *Anish Karmarkar
<>*
>
> 19/02/2008 05:19
>
>
> To
>
Michael Rowley <>
> cc
>
Scott Vorthmann <>, OASIS Assembly
> <>
> 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:]
> > 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
← Prev in month
← Prev in thread