Re: [sca-assembly] ISSUE 8 - Artifact resolution - proposal V4

[David Booz <booz@us.ibm.com>]

1) Is it considered an error if there is no location on import and there
is > 1 matching export? OR is the runtime allowed to pick one?

I don't have a strong feeling either way, though I tend to favor flexibility. I suspect that every vendor will run into cases where they want to extend the export selection capabilty, which in turn might require additional metadata extensions. If the spec where to declare an error case, then it would shut off the ability to do any extensions here. I understand that means we will give up some portability, I'm ok with that in this case.

2) I also am assuming that in the case there is exactly one matching
export in the Domain, the import is still allowed to set the location.

Absolutely. One matching export could be a temporal condition.



Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Anish Karmarkar ---09/23/2008 01:28:34 AM---David Booz wrote: > 1) @location is only needed when there is more than one matching export

From:	Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:	David Booz/Poughkeepsie/IBM@IBMUS
Cc:	sca-assembly@lists.oasis-open.org
Date:	09/23/2008 01:28 AM
Subject:	Re: [sca-assembly] ISSUE 8 - Artifact resolution - proposal V4

---

David Booz wrote:
> 1) @location is only needed when there is more than one matching export 
> in the Domain which provides the same artifact (e.g. QName).
> 

Ok, that makes sense.
Follow up Qs:
1) Is it considered an error if there is no location on import and there 
is > 1 matching export? OR is the runtime allowed to pick one?
2) I also am assuming that in the case there is exactly one matching 
export in the Domain, the import is still allowed to set the location.


> 2) Those mechanisms are covered earlier in the document, and pre-exist 
> this proposal. They'd be used before the SCA import/export mechanism 
> would as stated in the spec. I think Mike E said this on the last 
> telecon, just wanted to make sure.

I must have missed that, I joined late.
Thanks.

-Anish
--

> 
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
> Inactive hide details for Anish Karmarkar 
> <Anish.Karmarkar@oracle.com>Anish Karmarkar <Anish.Karmarkar@oracle.com>
> 
> 
>                         *Anish Karmarkar <Anish.Karmarkar@oracle.com>*
> 
>                         09/16/2008 10:26 AM
> 
> 		 
> 
> To
> 		 
> David Booz/Poughkeepsie/IBM@IBMUS
> 
> cc
> 		 
> sca-assembly@lists.oasis-open.org
> 
> Subject
> 		 
> Re: [sca-assembly] ISSUE 8 - Artifact resolution - proposal V4
> 
> 		 
> 
> 
> Two questions:
> 
> 1) Pseudo schema for import is as follows:
> <import namespace="xs:String" location=”xs:AnyURI”?/>*
> Why is location optional?
> 
> 2) Section 11.2.1 says:
> "1. from the contribution’s direct dependencies by resolving its sca
> import statements. Dependencies MUST NOT be searched recursively in
> order to locate artifacts.
> 2. from the contents of the contribution itself."
> 
> How do things like schemaLocation/wsdlLoction fit here? Is that
> considered to be part of bullet 2?
> 
> -Anish
> --
> 
> David Booz wrote:
>  > 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
>  >
>  >
>  > ------------------------------------------------------------------------
>  >
>  > ---------------------------------------------------------------------
>  > 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