Huang Kai wrote:
Hi, Raymond,
We encountered the same problem when implementing SDO's XSDHelper. Where we
used EMF's xsd tool package for resolve xsd. Wherein we just implemented our
own XSDSchemaLocator and added it to the resource's adapters, then we can do
everything in locating the import/include xsd. It works fine.
I don't know if XmlSchema have any thing alike.
Good point, and if we're going to tweak the resolution mechanism for
XSDs with some specific SCA resolution rules, then we need to make sure
that it's done in a consistent way:
- at runtime, under XmlSchema library
- at runtime, in the XSDHelper
- at codegen time (XSD generation and WSDL2Java)
- at codegen time under the JAX-WS / JAXB generators
- in my XSD editor
- in my XSD validator
- in my WSDL editor
- in my WSDL based Web Services test tool
- and in all the other Web Services implementations out there if we want
them to support these WSDLs and XSDs.
etc...
Does this still sound like a good idea?
... I'm not sure.
If we don't cover all these aspects, is this custom resolution going to
help the app developer? or get in his way?
... I'm positive that it'll get in his way :)
So I'm sure that we should use the SCA resolution within SCA artifacts.
Using it to resolve references between XSDs sounds either very
ambitious, or pretty dangerous to me...
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
