Yes, we've considered this also. However, I have a distaste for modifying XSDs given to us from 3rd parties. It forces one to modify the XSDs each time you take a new version from the 3rd party. It also means that when we distribute our XSDs that depend on 3rd parties, then all our clients have to do the same. Given that we have 300-400 XSDs, this is a non-trivial problem.
The reason we liked using the namespace as the public ID was because it
allowed for relatively concise XML catalogs. When we disseminate our
normative XSDs with and/or without dependencies, we could also include a
non-normative XML catalog. Consumers could then modify the catalog without
modifying the XSDs.
Modifying the XSDs is less painful if it is only done at build time and
then deployed. I'm going to need to think about whether we want to
continue this practice and/or use the XML catalogs with system IDs ...
Mark
From: Chad La Joie <laj...@itumi.biz>
To: j-users@xerces.apache.org
Date: 10/17/2011 07:30 AM
Subject: Re: JAXP XML Catalog Resolver for Public IDs
We've run in to this before as well. Is there any reason you can't
just change the schema locations to point to local files? That was
the only truly reliable method we could find that worked across all
our XML processing stacks.
On Mon, Oct 17, 2011 at 08:16, Mark R Maxey <mark_r_ma...@raytheon.com>
wrote:
>
> Thank you again for your insight and thorough response. This rocks our
world, but seeing the light is better than living in darkness.
>
> As I mention before, our problem is that we have hundreds of XSDs with
un-resolvable schemaLocations. We use JAXB to generate the XML-to-Java
binding and JAXP to do XSD validation. Since JAXB equated the namespace to
the publicId, we mistakenly thought JAXP would as well.
>
> My take away from all of this is that the only reliable, standards based,
cross parser solution to our problem is to generate an XML catalog
containing systemId mappings for each XSD. If anyone else has another
solution, I'd be interested in hearing it.
--
Chad La Joie
www.itumi.biz
trusted identities, delivered
---------------------------------------------------------------------
To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org
For additional commands, e-mail: j-users-h...@xerces.apache.org
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
