Jean-Sebastien Delfino wrote:
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,
Well, maybe we SCA spec guys are more than a little crazy ;-)
We had envisaged that for SCA, the Domain is built up from contributions
- and that the contributions form a way of sharing artifacts, if
required. This is deliberately intended to cover XML artifacts which
not only include SCA things like Composites, but also XSD and WSDL.
The idea is in principle a simple one - avoid using a plethora of
separate mechanisms, which force the developer to supply a lot of
detailed information. Instead have one simple overarching scheme that
can be used for all artifacts.
Maybe we had too much of the fruits of the vine when we devised this,
but it is in many ways a kind of extension of the ideas of OSGi bundles,
applied to the non-Java code artifacts that abound in these systems.
Regarding use cases like XSD editing and WSDL editing, I would tend to
agree that it would be best to do this in a situation where all
referenced artifacts are in simple places (I recall the recent
discussion between us about loading the XSDs into the Eclipse
configuration location rather than relying on the location parameters in
include elements....). So perhaps only some of these scenarios need
dealing with "in the SCA way" - and that these should focus on the
runtime.
However I can envisage that Eclipse STP may like to take on the
challenge of creating SCA contributions with SCA resolution of artifacts
from other contributions. Perhaps it isn't so crazy - it just needs a
divide and conquer approach.
Yours, Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
