Re: [jira] Commented: (XERCESC-1309) schemaLocation declared in instance document overrides validator properties

[Alberto Massari <am...@progress.com>]

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: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org