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.
Thanks again ...
Mark Maxey
From: Michael Glavassevich <mrgla...@ca.ibm.com>
To: j-users@xerces.apache.org
Cc: blaise.doug...@oracle.com, Mark R Maxey
<mark_r_ma...@raytheon.com>, Morgan T Davis <mt...@raytheon.com>, Rick D Brown
<rick_d_br...@raytheon.com>
Date: 10/15/2011 01:52 PM
Subject: Re: JAXP XML Catalog Resolver for Public IDs
Mark,
Mark R Maxey <mark_r_ma...@raytheon.com> wrote on 10/14/2011 06:03:08 PM:
> Thank you for your quick response.
>
> I'll confess we've struggled mightily with XSD resolution. We turned
> to XML catalogs hoping the namespace to URI mapping would allow us
> to work around invalid schemaLocations. Our (bad?) idea was to use
> catalogs preferring public IDs to resolve all imports of the same
> namespace to the same XSD that in turns transitively includes all
> other XSDs in that namespace.
>
> Just to make sure I understand you - are you saying that public IDs
> are only set through external entity declarations and if such a
> declaration doesn't exist it is "null"?
That's precisely what I'm saying. The publicId parameter of
LSResourceResolver.resolveResource() is defined as "The public identifier
of the external entity being referenced, or null if no public identifier
was supplied or if the resource is not an entity." An XML Schema document
is not an entity.
> This seems to make sense for
> arbitrary XML documents containing external entity declarations
> using public IDs. However, I don't understand how it makes any sense
> for XSDs resolving include & import schemaLocations.
>
> Is this something that is parser specific?
I think the idea that a schema's target namespace might be interchangeable
with a public ID comes from a time when the resolver APIs that were
available were more primitive. Specifically thinking of
org.xml.sax.EntityResolver whose resolveEntity() method only has publicId
and systemId parameters. That interface was only designed for resolving
external entities (i.e. the external DTD subset and external
general/parameter entities), but has been used in practice for resolving
other types of resources such as XML Schema documents.
Some implementers apparently thought it would be a good idea to pass the
schema's namespace as the publicId parameter. Xerces doesn't do that.
Though I don't really agree with it I can understand why others did it,
particularly if there were no alternatives for their users' applications to
get a hold of the namespace. So yeah, it's implementation specific
behaviour. No standard I've ever seen says they ought to be doing that.
Prior to DOM Level 3, if you needed the namespace URI from Xerces you could
have always dropped down to the XNI layer and extracted it from the more
schema-aware XMLEntityResolver [1].
> For example, Blaise
> Doughan recently posted a JAXB example using catalogs using both the
> system & public IDs but without any entity declarations. About 2/3
> of the way down, he says "This import requires a public mapping
> based on the namespace URI:". This agreed without our misguided
> belief that public IDs for XSDs were their namespace.
>
> It sounds like the only viable interoperable solution across tools &
> vendors is to create catalogs containing a system or systemSuffix
> mapping for every XSD include & import to a resolvable URI for that
> resource. If you have any other solutions, I'd appreciate your feedback.
Some would argue [2] that a schema location URI != a system ID and that you
should be looking at uri entries in the catalog instead. If you're working
with libraries that allow you to plug in your own resolver you can map the
parameters any way you want on to the catalog. I suppose the JAXB RI's XJC
compiler just does whatever it thinks is right with a catalog but provides
no mechanism to override it.
> Thanks!
>
>
> Mark
Thanks.
[1]
http://xerces.apache.org/xerces2-j/javadocs/xni/org/apache/xerces/xni/parser/XMLEntityResolver.html
[2] https://issues.apache.org/jira/browse/XERCESJ-1104
Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org<<inline: graycol.gif>>
<<inline: ecblank.gif>>
