sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] ISSUE 8 - Artifact resolution - proposal V5
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Assembly" <sca-assembly@lists.oasis-open.org>
- Date: Tue, 2 Sep 2008 11:47:23 +0100
Folks,
Here is an updated proposal and some
responses inline below to Dave's comments.
Note that the updated proposal DOES
NOT contain any material relating to the @override
attribute that I discussed in an earlier
email - I would prefer some discussion of that idea
before creating spec text for it.
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
David Booz <booz@us.ibm.com> wrote on 19/08/2008
14:39:52:
> Re: [sca-assembly] ISSUE 8 - Artifact resolution - proposal V5
>
> David Booz
>
> to:
>
> sca-assembly
>
> 19/08/2008 14:57
>
> I'm finding that wording this resolution is very difficult. I
think this
> is an improvement.
>
> I have a couple of reactions to the updates:
>
> 1) I would prefer to talk about the SCA artifact resolution mechanism
in
> general rather than specific to namespace import/export. While
it's true
> that the assembly spec only defines importing/exporting namespaces,
it
> needs to set the rules for how this mechanism works in general to
get some
> consistency across the specs. I don't want to allow the namespace
> specificity in the words to be used by any language binding TC as
a license
> to do something completely different when they define their language
> specific extensions. Line 3125-3132 should be in their own section
of the
> document (or merged into section 11.2.2) as they are specific to namespace
> import/export.
>
I've done some rewording
to help with this - the material is largely about XML artifacts and now
says so - and indicates
that specialization of the mechanism will apply to other artifact types.
> 2) line 3136 - import statements don't necessarily identify locations.
> They have to be resolved before a location is known. I suppose
we should
> insert a paragraph about import resolution. You came close to doing
that in
> 3129-3132. For example, we need to say that if there are two
contributions
> which both export the same thing, what happens?
I've added material to
address this. You may not like my choices ;-)
>
> 3) Did not follow the example you added, and in fact if I read it
correctly
> is an alteration of the design. You might be hinting at what
OSGI calls
> split package semantics, but I'm not sure.
I certainly intended to
allow for a given namespace to have entities declared in multiple locations.
The text makes this much
clearer now.
You may still object to
that function, of course.
I also clarified the example.
>
> 4) You're re-word of my example is good.
>
> I'll note that the text does not yet deal with circular dependencies
and
> split packages. I was hoping to get a split package use case
from Anish to
> help us flesh this out some more.
I think that circular dependencies
are nailed. The search is 1-deep only, whereever you start from.
Either you find the artifact(s)
in the specific set of locations identified, or its an error. The
fact
that some contribution
used as a location happens to also import the same namespace that it
exports is neither here
nor there - the presence of that import cannot affect the resolution of
an
artifact that some other
contribution is importing.
Split packages I've made
clearer - my use case is hinted at - import WSDL from Contribution A
and the XSD(s) for the
data types from Contribution B, all in the same namespace. That this
is
possible is clear - that
it is common practice is a fact of life - hence we need to permit this
kind
of arrangement for XML
files. It is not going to be allowed for all artifact types - Java
in
particular can't handle
this.
>
>
> Dave Booz
> STSM, BPM and SCA 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
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
Issue8-proposal-v6-sca-assembly-1.1-spec-cd01.pdf
Issue8-proposal-v6-sca-assembly-1.1-spec-cd01.doc
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]