Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] XML Catalog - namespaces or schemaLocations ... or both

Thank you, Valentin, for the helpful reply.

One fairly dumb question first:  without digesting all the nuances of the OASIS specification, what exactly are the differences between the "public", "system", and "uri" extensions?  It looks like org.eclipse.jst/wst.standard.schemas use primarily "public" for DTD's and "uri" for schemas, whether it be by namespace or by schema location.  I don't grasp the significance of the one use of "system" I can find, which is in org.eclipse.wst.xsd.core.

It looks like we should continue to simply provide the schema location redirect (web location mapped to file location) in org.eclipse.jst.standard.schemas and provide any additional namespace redirects (namespace mapped to file location) within Dali itself, whether we choose to do that as a simple catalog contribution or a more complicated XSLT-type solution.  I'm not sure I'd feel comfortable with tying the user to a single namespace-schema version mapping, especially in such a common location.

One additional question:  is it possible (either for a plugin provider or for a user) to map a namespace to a web location of a schema?  Relatedly, is it possible to map a namespace to a web location, which itself is then mapped to a local location, perhaps in an existing plugin?  (for example, plugin provider provides a local schema foo.xsd, for which he adds the xml catalog entry "" -> "schemas/foo.xsd".  User Sue doesn't want to use schema locations in her XML files, so she chooses to map the namespace "" to the web location "" (since she can't refer to schemas in other plugins).  But since the web location she specified is already mapped to a local (plugin) file location, her namespace mapping in effect resolves to the local schema file.)  I know that some of this is impossible in effect (I can't choose a web location for a schema catalog entry, for instance), but is it possible in theory?

Thanks again!
Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development

Valentin Baciu wrote:

Hi Paul,

Both use cases are valid and supported by the WTP XML catalog and the WTP XML editor and validator.  I have seen use case #1 used for example by the JEE schemas when a number of different schemas located at different URIs share the same namespace. The schema location is used to specify what "subset" is to be used.  I have seen use case #2 used for example in the web services (WSDL, XSD) domain, where the WSDL and XML schema documents are not typically specifying the xsi:schemaLocation hint, relying instead on the namespace URI.

Here's my take on answering your questions:

a) As Dave Carver mentioned in his reply (thanks Dave) this scenario "one namespace -> multiple schema versions" is already "out there" for example in the XSLT domain. The XSLT 2.0 specification chose to keep the same target namespace - -  as the one used by XSLT 1.0 specification, with the discriminator being the value of the version attribute specified on the root element. The persistence.xml scenario appears to be similar, with the root element defining a version attribute.

The XML catalog will return the first  schema location -> schema location mapping it finds and similar for the namespace -> schema location mapping, and user entries override the system catalog (plug-in contributions). The Oasis XML catalog specification, partially implemented by the WTP XML catalog, does not appear to provide a way to map to multiple versions of a resource based on a version discriminator.

b) The xsi:schemaLocation is normally providing just a hint The WTP XML catalog resolver works like this: it always honours the xsi:schemaLocation when specified and only tries to use the namespace URI when no xsi:schemaLocation is specified. So as long as let's say v.1 and v.2  schemas are located at different URIs  and catalog mappings exist for those URIs the tools should work just fine with XML instances like the one in scenario 1 for both versions.

c) You are right, a user cannot use the XML catalog UI to point to a location in a plug-in jar, that type of location can only be specified through an XML catalog contribution (extension). However, the user can add a mapping by saving the (new) schema version into the workspace or file  system and creating a new user XML catalog entry. There is a little bit of magic in the XML Catalog UI: when selecting an XML schema file in the location field, the Key Type selection box content will be refreshed to provide two options: Namespace Name and Schema Location. Namespace Name maps to the mapping from scenario 2 above, and creates a "uri" catalog mapping. Schema Location actually creates a "system" catalog mapping, which is equivalent to the mapping for scenario 1 above.

d) I would think that specifying both types of mappings should be fine. By shipping the persistence schema and binding it by its remote schema location (scenario 1) you're ensuring that the tools will work in "disconnected mode", avoiding the need to download and cache the schema on first use. For scenario 2 to work you must bind the location because the namespace URI does not de-reference an actual schema. The editor/validator will try to de-reference the namespace URI as a last resort in obtaining a schema and failing that the user will get no content assist or validation.

A similar pair of mappings are contributed for example by the XML schema tools for the XML schema namespace and schema location. You can check out these entries in the system catalog. They look like this:

  <system systemId="" uri="...."/>
  <uri name="" uri="..."/>

If in the future this type of version driven schema location becomes widespread, and use case 2 is preferred (as in the XSLT case), perhaps we could:
        - enhance the XML catalog resolver to directly support this scenario
        - generalize the XSLT custom resolver approach suggested by Dave and make it available as API
        - come up with some other mechanism to support this scenario

I hope this helps.

Valentin Baciu
WTP XML Web Services Tools

Here's Dave's reply for reference:

> So, there are a few problems here.
> a)  The namespace-version problem.  Can we use the namespace-to-schema
> location mechanism reliably, knowing that there may (will) be multiple
> schema versions per namespace?

This is an issue we experienced in the XSL Tools incubator project,
because XSLT 1.0 and XSLT 2.0 use the same namespace.   The way we
handled this was by using a custom URIResolver.   Take a look at the
org.eclipse.wst.xsl.core project in the incubator/sourceedting/plugins
directory for an example.


From: Paul Fullbright <paul.fullbright@xxxxxxxxxx>
To: "General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
Date: 07/28/2008 05:20 PM
Subject: [wtp-dev] XML Catalog - namespaces or schemaLocations ... or both

This is an issue we've run into a few times with our schema locations and proxies, have gone two different directions at two different times, and are less sure than ever which way we're supposed to go with it.

We'd like to support both of these use cases:

1 - Automatic validation for XML of form:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"

This requires us to set up an entry in org.eclipse.jst.standard.schemas of:

       uri="dtdsAndSchemas/persistence_1_0.xsd" />

such that the schema location actually redirects to the locally stored file.  (Check for background.)

2 - Automatic validation for XML of form:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0"

This seems to require us to set up an entry in org.eclipse.jst.standard.schemas of:

       uri="dtdsAndSchemas/persistence_1_0.xsd" />

such that the namespace is used to retrieve the correct schema.  The problem that seems to come from this approach is the possibility of multiple schema versions using the same namespace, which they usually do.

So, there are a few problems here.  

a)  The namespace-version problem.  Can we use the namespace-to-schema location mechanism reliably, knowing that there may (will) be multiple schema versions per namespace?

b)  If not, must we always generate XML of the first form, and count on the user setting up his workspace catalog to take advantage of namespace entries, assuming that the user will only be working with one version of the schema in this case?

c)  The problem of a user specifying a namespace->schema location for one of our included schemas.  As far as I know (I wasn't able to) a user can't set up a catalog entry whose key is a namespace and whose schema is included in the plugin jars.  (Additionally, I'd expect that if a user specified a namespace-to-web location of a schema catalog entry, and that web location was further mapped to a local schema, as in use case #1 above, that eclipse would automatically use the local schema for validation.)  Does this mean that, if a user wants to not have schemaLocation tags, that she would have to download her own copy of the schema to use locally?

d)  Should we provide both entries in the org.eclipse.jst.standard.schemas plugin and hope for the best?

Paul Fullbright
Oracle Corp.
Eclipse Dali/Java Persistence Tools Development
wtp-dev mailing list

_______________________________________________ wtp-dev mailing list wtp-dev@xxxxxxxxxxx

Back to the top