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"?  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?  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.


Thanks!


Mark



                                                                       
  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/14/2011 02:51 PM                                      
                                                                       
  Subject:    Re: JAXP XML Catalog Resolver for Public IDs             
                                                                       





Mark,

This is not a bug. A public ID is not a target namespace or vice versa.
Xerces passes the parameters in their correct positions [1] to the
LSResourceResolver.

If you want to process a namespace URI as if it were a public ID you can
extend the XMLCatalogResolver and override resolveResource() to do that.

Thanks.

[1]
http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSResourceResolver

Michael Glavassevich
XML Parser Development
IBM Toronto Lab
E-mail: mrgla...@ca.ibm.com
E-mail: mrgla...@apache.org

Mark R Maxey <mark_r_ma...@raytheon.com> wrote on 10/14/2011 03:20:36 PM:

> Xerces Java Users,
>
> Xerces is failing to correctly resolve XSDs to their locations using
> XML catalogs that prefer public IDs during the loading of the XSDs
> for schema validation. After extensive debugging, we've found that
> the following method out of XMLCatalogResolver is always passed a
> "null" for the publicId :
>
>            public   LSInput  resolveResource( String  type, String
> namespaceURI,
>                    String  publicId, String  systemId, String  baseURI) {
>
> This prevents XMLCatalogResolver from being able to use public IDs
> to resolve schema references.
>
> Further debugging indicates the possible problem/solution lies in &
> around line 957 of XSDHandler. This seems like it is the appropriate
> place to set the public ID to be the name of the schemaNamespace.
>
>
> Has anyone encountered these issues before? Let us know if you have
> difficulty reproducing the issue. If you agree it is a bug, I'll be
> glad to submit it to JIRA.
>
>
> Thanks!
> Mark Maxey

<<inline: graycol.gif>>

<<inline: ecblank.gif>>

Reply via email to