Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] Question about XML Catalog Contributions

Another way to solve this is to not use namespace uri as schema location.
That way right in the descriptor, you can map the same namespace URI to
different schema locations that hold schemas at different version levels.
The nice thing about this approach is that it is transparent to the user.
They can look at the file to see exactly where the schema is coming from. If
there is any ambiguity, they have a URL to paste into the browser to pull up
exactly the version that is referenced. This also provides relatively
straightforward version transitions. Just change the schema location

To integrate this with XML Catalog, you map the schema location URL to the
plugin resource instead of the namespace URI.

In tooling, there is typically a version that's implicit in the context.
Maybe something like the facet version. You can validate context version
against the expected schema location URI to make sure they match and flag a
problem if they don't (with quick fixes if you want to be fancy).

This is the approach that we took in Oracle's Eclipse tooling when dealing
with WebLogic Server descriptor schemas.

- Konstantin

-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Jesper Steen Møller
Sent: Friday, October 02, 2009 2:26 PM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] Question about XML Catalog Contributions

We had this problem in XSL Tools, and ended up writing a specialized
resolver for it which peeked the version and returned the correct
schema. Having to write a resolver for each such schema doesn't scale
well in the general case, and is hidden from the user (i.e. doesn't
show up in the catalog), but it gets the job done.

I forget if the XML Catalog spec welcomes extensibility, but since
processors such as Xerces resolve schema locations by looking at 'uri'
entries in the catalog, it would make sense to add it there, using
e.g. xpath:

  <uri name="";
  <uri name="";

using the catx:version attribute as a tie-breaker when matching
catalog entries (this assumed that the version is an attribute on the
root element). Or, even more general:

  <uri xmlns:orm="";
      catx:test="//orm:entity-mappings/@version = '2.0'"/>

I guess this could be prototyped into the Eclipse Catalog support to
see if it is viable.

However, the standards compliant way is to use XML Schema 1.1 which
supports conditional type assignment, so it will be possible to have a
schema for entity-mappings which has a dynamically determined type for
any given particle.  But this requires involvement of the schema
author, and commitment to XML Schema 1.1.

On Fri, Oct 2, 2009 at 10:45 PM, Paul Fullbright
<paul.fullbright@xxxxxxxxxx> wrote:
> Does anyone know if there is a way to take document version into
consideration when registering a schema for a namespace?
> Java Persistence uses the same namespace for all versions of their
documents, and so it seems only possible to register the latest version of
the schema for validation for that namespace, and documents such as:
> <?xml version="1.0" encoding="UTF-8"?>
> <entity-mappings version="1.0"
>   xmlns="";
>   xmlns:xsi="";>
> </entity-mappings>
> show up as invalid since the version does not match the fixed value of
"2.0" required by the latest version of the schema.  (Also, any new elements
or attributes for 2.0 would show up as valid, even if not valid for 1.0.)
> --
> Paul Fullbright
> Eclipse Java Persistence Tools (Dali) Development
> Oracle
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
wtp-dev mailing list

Back to the top