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 "http://www.foo.org/foo.xsd"; ->
"schemas/foo.xsd". User Sue doesn't want to use schema locations in her
XML files, so she chooses to map the namespace "http://www.foo.org/foo";
to the web location "http://www.foo.org/foo.xsd"; (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
[EMAIL PROTECTED]
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
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."
<[email protected]>
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"_
<http://java.sun.com/xml/ns/persistence>
xmlns:xsi=_"http://www.w3.org/2001/XMLSchema-instance"_
<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"_
<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"_*
<http://java.sun.com/xml/ns/persistence>
xmlns:xsi=_"http://www.w3.org/2001/XMLSchema-instance"_
<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"_
<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]
<mailto:[EMAIL PROTECTED]>_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
------------------------------------------------------------------------
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
