Neither the JAXP or JAXB specs mention XML Catalogs at all. JAXP only provides plug-in points. It's up to the user to glue in a resolver that meets their needs.
The XML Catalog support provided by the JAXB RI (reference implementation) tools is implementation specific. Some other implementation may choose to do something else. I know users often don't make the distinction between specifications and their implementations (especially with the JSRs that get bundled in the JDK), but you can't always blame the specs for why the world isn't as sensible as it ought to be. Thanks. Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org Chad La Joie <laj...@itumi.biz> wrote on 10/17/2011 08:51:09 AM: > Yeah, the unfortunate part is that each of the individual specs in the > XML suite of specs just isn't defined in such a way to play as nicely > as you'd hope with other specs. > > In our case we rarely have changes to the schema so we just change > them once and stick them in our SVN repo with the code. This also > helps us mitigate potential schema injection attacks in the places > where we choose to do so. > > On Mon, Oct 17, 2011 at 08:46, Mark R Maxey <mark_r_ma...@raytheon.com> wrote: > > > > 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 > > > > > > Chad La Joie ---10/17/2011 07:30:51 AM---We've run in to this > before as well. Is there any reason you can't just change the schemalocations > > > > > > 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 > > > > > > > > -- > 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
