Simon Laws wrote:
> Hi Ram
I don't think there is a good reason for them to be different. It
seems that the OASIS spec now adds more detail to the artifact
resolution section of the spec but I don't think this added detail
means that the behaviour changes.
We do though need to run the "step 4" question to ground. So far, in
the context of TUSCANY-2906, it seems that the conversation has come
down to whether step 4 in our list of steps could be considered to be
part of the artifact specific resolution mechanism.
It has been pointed out that the artifact specific and sca
(imports/exports) mechanism should not be mixed. Sounds sensible as if
you were going to rely on the SCA mechanism you would have included an
import for the namespace you require.
It has also been pointed out that the artifact specific mechanism is
extremely flexible and the runtime could decide to look in the current
contribution to find artifacts where the location hint doesn't help
So on this basis do we summarize this by saying that we take step 4 at
face value when it talks about looking in the *current* contribution
and include it in the artifact specific resolution process?
Simon
Folks,
I think that the idea of looking into the current contribution is the wsdlLocation (or xsdLocation)
fails is OK - ie "step 4".
That can't be regarded as "using the SCA resolution mechanism" since that would imply looking at the
imports and at the contributions exporting those namespaces (etc).
Just looking at the local contribution seems ok as a part of "the artifact specific resolution
mechanism". Of course, this begs the question of why you would ever bother with wsdlLocation if you
have a local copy of the target WSDL in the first place. Seems much easier to simply have the local
copy and no wsdlLocation attribute - SCA runtime will happily find the WSDL for you in that case and
you would have saved yourself some work into the bargain ;-)
Yours, Mike.
