You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2007/07/25 00:46:18 UTC
[XmlSchema] Pluggability for XSD import/include resolvers?
Hi,
We currently use XmlSchema to load XSDs. To resolve the import/include
directives using our schemes, we provide an implementation of
org.apache.ws.commons.schema.resolver.URIResolver and set it to
org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the
schemaLocation attribute for the <xsd:import> or <xsd:include> is set.
Now we would like to handle the cases where the schemaLocation attribute is
not present. For example, <xsd:import namespace="http://ns1"/>. Without the
schemaLocation, we resolve the import/include by namespace. In this case, we
already have a map keyed by namespace for a list of XmlSchema objects loaded
from a catalog or other files and we want to reuse them. Would it be
possible to open the XmlSchemaCollection.getSchema(SchemaKey) method so that
we can override/customize the behavior to associate existing XmlSchema
instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection to
keep the schema map is not always feasible.
Another observation is that a NPE will be thrown if the
URIResolver.resolveEntity() returns null. Is there any way to disable the
aggressive resolving/loading of import/include?
rfeng@apache.org
Raymond Feng
Apache Tuscany
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Posted by Raymond Feng <en...@gmail.com>.
Hi,
If I understand the SCA assembly spec correctly, the SCA resolution
mechanism will be used when the "schemaLocation" is not present. For
example, let's assume a.xsd has an import statement as follows:
<import namespace="http://ns1"/>
We're going to use the namespace (http://ns1) as the key to find the
matching schema (which contains the type/element definitions referenced by
a.xsd) from another artifact(s).
Thanks,
Raymond
----- Original Message -----
From: "Mike Edwards" <mi...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, July 25, 2007 6:33 AM
Subject: Re: [XmlSchema] Pluggability for XSD import/include resolvers?
> Raymond,
>
> How does this relate to the contribution resolution mechanism described by
> the SCA specifications?
>
> Yours, Mike.
>
> Raymond Feng wrote:
>> Hi,
>>
>> We currently use XmlSchema to load XSDs. To resolve the import/include
>> directives using our schemes, we provide an implementation of
>> org.apache.ws.commons.schema.resolver.URIResolver and set it to
>> org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the
>> schemaLocation attribute for the <xsd:import> or <xsd:include> is set.
>>
>> Now we would like to handle the cases where the schemaLocation attribute
>> is not present. For example, <xsd:import namespace="http://ns1"/>.
>> Without the schemaLocation, we resolve the import/include by namespace.
>> In this case, we already have a map keyed by namespace for a list of
>> XmlSchema objects loaded from a catalog or other files and we want to
>> reuse them. Would it be possible to open the
>> XmlSchemaCollection.getSchema(SchemaKey) method so that we can
>> override/customize the behavior to associate existing XmlSchema instances
>> to a SchemaKey? BTW, using a singleton of XmlSchemaCollection to keep the
>> schema map is not always feasible.
>>
>> Another observation is that a NPE will be thrown if the
>> URIResolver.resolveEntity() returns null. Is there any way to disable the
>> aggressive resolving/loading of import/include?
>>
>> rfeng@apache.org
>> Raymond Feng
>> Apache Tuscany
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Posted by Mike Edwards <mi...@gmail.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Posted by Huang Kai <pr...@gmail.com>.
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.
----- Original Message -----
From: "Mike Edwards" <mi...@gmail.com>
To: <tu...@ws.apache.org>
Sent: Wednesday, July 25, 2007 9:33 PM
Subject: Re: [XmlSchema] Pluggability for XSD import/include resolvers?
> Raymond,
>
> How does this relate to the contribution resolution mechanism described
> by the SCA specifications?
>
> Yours, Mike.
>
> Raymond Feng wrote:
>> Hi,
>>
>> We currently use XmlSchema to load XSDs. To resolve the import/include
>> directives using our schemes, we provide an implementation of
>> org.apache.ws.commons.schema.resolver.URIResolver and set it to
>> org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the
>> schemaLocation attribute for the <xsd:import> or <xsd:include> is set.
>>
>> Now we would like to handle the cases where the schemaLocation attribute
>> is not present. For example, <xsd:import namespace="http://ns1"/>.
>> Without the schemaLocation, we resolve the import/include by namespace.
>> In this case, we already have a map keyed by namespace for a list of
>> XmlSchema objects loaded from a catalog or other files and we want to
>> reuse them. Would it be possible to open the
>> XmlSchemaCollection.getSchema(SchemaKey) method so that we can
>> override/customize the behavior to associate existing XmlSchema
>> instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection
>> to keep the schema map is not always feasible.
>>
>> Another observation is that a NPE will be thrown if the
>> URIResolver.resolveEntity() returns null. Is there any way to disable
>> the aggressive resolving/loading of import/include?
>>
>> rfeng@apache.org
>> Raymond Feng
>> Apache Tuscany
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
Re: [XmlSchema] Pluggability for XSD import/include resolvers?
Posted by Mike Edwards <mi...@gmail.com>.
Raymond,
How does this relate to the contribution resolution mechanism described
by the SCA specifications?
Yours, Mike.
Raymond Feng wrote:
> Hi,
>
> We currently use XmlSchema to load XSDs. To resolve the import/include
> directives using our schemes, we provide an implementation of
> org.apache.ws.commons.schema.resolver.URIResolver and set it to
> org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the
> schemaLocation attribute for the <xsd:import> or <xsd:include> is set.
>
> Now we would like to handle the cases where the schemaLocation attribute
> is not present. For example, <xsd:import namespace="http://ns1"/>.
> Without the schemaLocation, we resolve the import/include by namespace.
> In this case, we already have a map keyed by namespace for a list of
> XmlSchema objects loaded from a catalog or other files and we want to
> reuse them. Would it be possible to open the
> XmlSchemaCollection.getSchema(SchemaKey) method so that we can
> override/customize the behavior to associate existing XmlSchema
> instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection
> to keep the schema map is not always feasible.
>
> Another observation is that a NPE will be thrown if the
> URIResolver.resolveEntity() returns null. Is there any way to disable
> the aggressive resolving/loading of import/include?
>
> rfeng@apache.org
> Raymond Feng
> Apache Tuscany
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org