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: sca-assembly@lists.oasis-open.org
- Date: Wed, 20 Aug 2008 10:42:51 +0100
Dave,
I know that we discussed some of these
points on the call yesterday, but I think it is worth replying in
back & white so that everyone gets
a clear picture.
I will have a go at another version
of the document at some point, based on my responses.
Comments inline as <mje>...</mje>
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
From:
| David Booz <booz@us.ibm.com>
|
To:
| sca-assembly@lists.oasis-open.org
|
Date:
| 19/08/2008 14:57
|
Subject:
| Re: [sca-assembly] ISSUE 8 - Artifact
resolution - proposal V5 |
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.
<mje>
The funny thing is that
I thought I WAS being general. It seems as if you interpret
"namespace" to
mean "XML namespace", whereas I was assuming more generality
in that Java packages assume
a Java namespace - and indeed it was my assumption,
perhaps incorrect, that
any import mechanism would need some form of "namespace"
to control what was being
imported and exported, but that the precise definition of the
form and scope of the namespace
would vary depending on the type of artifact
involved.
But perhaps this needs
to be explained explicitly.
</mje>
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.
<mje> I agree that
the Assembly specs should a) lay down the general rules and b)
define explicit rules for
XML namespaces.
The spec should say this
explicitly
</mje>
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.
<mje> OK, I'll think
harder about the document structure</mje>
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?
<mje> OK, I thought
I had covered this but looks like I assume people will understand
more than the text says...</mje>
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.
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.
<mje>
We discussed split packages
on the call. There are 2 aspects to split packages
- packages split between
one contribution and a second contribution that the first one
imports from (this is the
classic case in OSGi)
- packages split between
two or more contributions that are imported by some
other contribution (not
allowed for Java packages in OSGi)
At the moment, I can see
uses for both - I will send a separate email discussing
split package usage.
Circular dependencies are
a different matter - I think we will need to spell out some
examples to understand
things better. There may not be a problem here.
</mje>
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
Mike Edwards
<mike_edwards@uk.
ibm.com>
To
"OASIS
Assembly"
08/19/2008 08:27
<sca-assembly@lists.oasis-open.org>
AM
cc
Subject
Re: [sca-assembly]
ISSUE 8 -
Artifact
resolution - proposal V5
Dave,
Great stuff.
I've done an update to try to clarify some of the language which I found
a
bit hard to parse. There is no attempt to change the
meaning of the proposal, so if it doesn't read right now, I've screwed
up:
Word & PDF formats for those who have trouble with Word alone - fully
change marked.
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
From: David Booz <booz@us.ibm.com>
To: sca-assembly@lists.oasis-open.org
Date: 18/08/2008 20:36
Subject: [sca-assembly] ISSUE 8 - Artifact resolution - proposal
V4
Here is the latest proposal for Issue 8. It includes the updated
words
from Mike E in section 6.6.
While I haven't received the use cases from Anish (AI 2008-07-22-3), I
took
a shot at rewording the body of the changes in 11.2.1 anyway.
This closes my AI 2008-07-22-4.
(See attached file: Issue8-proposal-v4-sca-assembly-1.1-spec-cd01.doc)
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[attachment
"Issue8-proposal-v4-sca-assembly-1.1-spec-cd01.doc" deleted by
Mike
Edwards/UK/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to 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
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
[attachment "Issue8-proposal-v5-sca-assembly-1.1-spec-cd01.pdf"
deleted by
David Booz/Poughkeepsie/IBM] [attachment
"Issue8-proposal-v5-sca-assembly-1.1-spec-cd01.doc" deleted by
David
Booz/Poughkeepsie/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to 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. Follow this link to 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]