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 http://www.w3.org/TR/xslt20/ chose to keep the same target namespace - http://www.w3.org/1999/XSL/Transform - as the one used by XSLT 1.0 specification http://www.w3.org/TR/xslt, 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 http://www.oasis-open.org/committees/entity/spec-2001-08-06.html, 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 http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#schema-loc. 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 http://java.sun.com/xml/ns/persistence/ 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="http://www.w3.org/2001/xml.xsd"; uri="...."/> <uri name="http://www.w3.org/2001/XMLSchema"; 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. Regards, 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. Dave From: Paul Fullbright <[EMAIL PROTECTED]> To: "General discussion of project-wide or architectural issues." <wtp-dev@eclipse.org> 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" xmlns="http://java.sun.com/xml/ns/persistence"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd";> ... This requires us to set up an entry in org.eclipse.jst.standard.schemas of: <uri name="http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"; uri="dtdsAndSchemas/persistence_1_0.xsd" /> such that the schema location actually redirects to the locally stored file. (Check https://bugs.eclipse.org/bugs/show_bug.cgi?id=227037 for background.) 2 - Automatic validation for XML of form: <?xml version="1.0" encoding="UTF-8"?> <persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> ... This seems to require us to set up an entry in org.eclipse.jst.standard.schemas of: <uri name="http://java.sun.com/xml/ns/persistence"; 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 [EMAIL PROTECTED] wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________ wtp-dev mailing list wtp-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/wtp-dev
