Hi,
Please see my comments inline.
Thanks,
Raymond
----- Original Message -----
From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 24, 2007 6:46 PM
Subject: Re: Resolving WSDL/XSD import/include for SCA contributions
Two questions inline.
Raymond Feng wrote:
Hi,
I'm working on the artifact processing of WSDL/XSD from SCA
contributions, especially for the import/include directives. I would like
to share what I have so far to get your feedback.
Let's assume we have the following artifacts ([1][2]).
* helloworld-service.wsdl (definition) imports helloworld-interface.wsdl
* helloworld-interface.wsdl (inline schema) imports greeting.xsd
* greeting.xsd includes name.xsd
For the import/include, we could have different ways to use the
"location" attribute for a WSDL <import>. Please note the SCA spec says
the explicit location attribute should be honored. If it's not present,
then we use the namespace-based resolution defined by SCA.
1. location="helloworld-interface.wsdl" (relative to the base document
where the import is defined)
2. location="/wsdl/helloworld-interface.wsdl" (relative to a SCA
contribution)
3. location="http://example.com/helloworld-interface.wsdl"; (absolute URL
pointing to an external resource)
4. location="" or location is not present: Use the namespace to resolve
the imported definition
Is location="" even valid? I didn't think so.
I have clarified this on the follow-up e-mail. The location attribute is
required for <import.wsdl>. "" doesn't seem to be a valid URI.
The absence of schemaLocation for <xsd:import> and <xsd:include> are valid
though.
We have two options here:
a) Plugin a tuscany-specific resolver for WSDL4J
(javax.wsdl.xml.WSDLLocator) and XmlSchema
(org.apache.ws.commons.schema.resolver.URIResolver).
This option can handle location case 1, 2 and 3. For 2, we probably need
some context from the contribution service.
The difficulty is that both resolvers expect to take an InputSource. For
location case 4 (empty or not present), we don't have a corresponding
InputSource.
I was going to respond with a long list of pros-cons for both options,
then deleted all my comments to ask a simple question :). Why can't we
return an InputSource for the contents of the imported document?
Well, for the import/include that can be resolved to a document, we return
the InputSource. I have said that it works for location case 1, 2 and 3. But
if the import/include only doesn't have the schemaLocation attribute, what
InputSource should we return?
A related question, for an artifact processer that loads multiple artifacts
following the import/include directives, how can we avoid the duplicate
loading? For example, we have a.wsdl imports b.wsdl, both a.wsdl and b.wsdl
are in the same contribution and they are processed by the WSDL artifact
processor. We probably don't want to load b.wsdl twice in this case.
To make WSDL4J happy, we might be able to provide a dummy InputSource
pointing to a byte array which contains the empty definition (AFAIK, null
InputSource won't work) and then resolve the imported definition by QName
during the resolve() phase.
b) Disable the import/include resolving feature and re-link the related
artifacts by Tuscany
There are two challenges:
How to disable the aggressive resolving of import/include?
How to re-link the artifacts after the fragments are loaded?
WSDL4J: We can disable the import processing by WSDL4J and then resolve
the imported artifacts in the different step. Some of the elements are
"undefined" and we have to navigate the WSDL4J model and resolve them.
During the procedure, we can use the location as a key to constrain the
scope of resolution.
XmlSchema doesn't seem to have a way to disable the aggressive resolving.
What do you guys think? Any opinions are welcome.
Thanks,
Raymond
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/wsdl
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/xsd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
