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
paul.fullbright@xxxxxxxxxx
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
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
paul.fullbright@xxxxxxxxxx_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
|
