Hi Jake,
At 14.11 15/12/2004 -0800, Jake Pieczonka (JIRA) wrote:
[ http://nagoya.apache.org/jira/browse/XERCESC-1309?page=comments#action_56741 ]
Jake Pieczonka commented on XERCESC-1309: -----------------------------------------
Alberto,
Thanks for spending time on this issue. I created a test case and I found the reason for the error. My schema had no targetNamespace declared and so was not being matched against the namespace declaration in the instance document. Hopefully this bug entry will serve as a lesson to others.
My goal is to declare exactly which schema I want to validate against programatically, but it appears that the instance document has quite a bit of leeway in determining how it gets validated.
I saw the redirect sample, and I can see how implementing the enity resolver might solve my particular problem, but I think it might have issues with multiple schemas. How can I ensure that elements within the default namespace are validated against my schema while elements in other namespaces are validated against their respective schemas?
Keep in mind that I may not know ahead of time what the actual default namespace will be. The reason for all this convoluted logic is to implement versioning. I have to ensure that instance documents are valid against the latest version of my schema, but they may have originally been written against a previous version using a different namespace.
You need to understand that each namespace URI must have one XMLSchema that defines how its elements and attributes should be; it doesn't matter if that namespace URI is associated to the default (empty) prefix, or to the prefix ns1 rather than ns2. What counts is the namespace URI.
So, once you call setExternalNamespaceLocation("URI file.xsd") you are guaranteed that any XML file that uses that namespace will use your file.xsd as schema, regardless of the prefix they chose to use.
If you still want to validate previous versions, you can pre-load all those schemas, e.g. calling setExternalNamespaceLocation("URIv1 filev1.xsd URIv2 filev2.xsd URIv3 filev3.xsd").
Is there a possibility of changing setExternalNoNamespaceLocation to override the schemaLocation attribute located in the instance document? Would this break any other logic? I'm not sure what all the implications might be, but if it doesn't break anything, I know this feature request would be useful to at least one person. ;)In general, the XML instance could want to load the schema for namespace X, because it uses elements coming from that namespace; in this case blindly replacing the xsi:schemaLocation attribute with your own could make the XML invalid (because of missing schemas).
You are better off if you create an entity resolver that work as a catalog: every time Xerces needs to load a schema, it will tell you the namespace URI and the location where the schema should be available; the catalog has a map that associate a set of namespace URI to a location (in memory, or in the file system) where a copy of that schema can be found, and builds an InputSource out of this source.
If you want to be restrictive, you return an InputSource with an empty content for those namespace URI that you cannot find in the map; otherwise you return NULL and let Xerces try to load the schema from the suggested location. Clearly the restrictive approach could lead to schema validation errors, if that schema was necessary to validate the entire document.
This kind of catalogs are usually create for performance reason (i.e. avoiding accessing Internet all the times a validation is performed), but they can be used for security reasons too (if you place in the catalog only the schema you trust).
Hope this helps,
Alberto
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
