Oh, and just to be clear. I'm not saying that's a Xerces problem. It was just a general gripe.
On Mon, Oct 17, 2011 at 09:50, Chad La Joie <laj...@itumi.biz> wrote: > Yeah, I wasn't referring to the impls, though those do have their own > composition problems. I was referring to the specs themselves. XML, > XML Namespaces, xml:, XML Schema, and others just don't compose as > nicely as one would hope. > > On Mon, Oct 17, 2011 at 09:39, Michael Glavassevich <mrgla...@ca.ibm.com> > wrote: >> 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 > > > > -- > Chad La Joie > www.itumi.biz > trusted identities, delivered > -- 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
