[ 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. 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. ;) > schemaLocation declared in instance document overrides validator properties > --------------------------------------------------------------------------- > > Key: XERCESC-1309 > URL: http://nagoya.apache.org/jira/browse/XERCESC-1309 > Project: Xerces-C++ > Type: Bug > Components: Validating Parser (Schema) (Xerces 1.5 or up only) > Versions: 2.5.0, 2.6.0 > Environment: Solaris 2.8, Forte 6.2 patch 5, built from source for both > 2.5.0 and 2.6.0 > Reporter: Jake Pieczonka > Priority: Critical > > I am writing some code to validate documents against a given schema: > parser = new XercesDOMParser; > errorHandler = new ValidatorErrorHandler; > parser->setErrorHandler(errorHandler); > parser->setValidationScheme(XercesDOMParser::Val_Always); > parser->setDoNamespaces(true); > parser->setDoSchema(true); > //parser->setExternalSchemaLocation(schemaLocationWithNS.c_str()); > parser->setExternalNoNamespaceSchemaLocation(schemaLocation.c_str()); > parser->cacheGrammarFromParse(true); > The code should override any schema declarations in the instance document. > It works as expected when no schema declarations are present, and also > correctly overrides any noNameSpaceSchemaLocation declared in the document. > However, if the document contains a schemaLocation declaration, then the code > above fails to override it and the schema is loaded from the location > contained in the document. > Here is a sample declaration: > <rootElement xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://exploit.com/schema > http://www.exploit.com/schemas/exploitSchema.xsd"/> > I am flagging this as cricital because of the possible security > considerations. Instance documents should not be able to override the schema > location declared by the program, since it then becomes a trivial matter to > pass untrusted data to a program which is expecting validated input. > Note that using the commented-out line above to set the schema location in > the program also fails to override the document setting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
