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.
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?
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]
