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 8 - Artifact resolution - proposal V5



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]