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 --------------------------------------------------------------------- To unsubscribe, e-mail: j-users-unsubscr...@xerces.apache.org For additional commands, e-mail: j-users-h...@xerces.apache.org
