Re: Using fgXercesSchemaExternalSchemaLocation to set a schema path.

[Steve Harrington]

Correct me if I'm wrong, but I think the problem is that she needs to use:
virtual void setProperty (const XMLCh *const name, void *value)=0
instead of:
virtual void setFeature (const XMLCh *const name, const bool state)=0
Cheers,
Steve Harrington
National Radio Astronomy Observatory
[EMAIL PROTECTED] wrote:
Hi,
I am trying to set the feature  fgXercesSchemaExternalSchemaLocation to 
a schema path
Using Visual C++ and it blows up. I am using the following code.
 
// Begin code.

DOMImplementation *pImpl = 
DOMImplementationRegistry::getDOMImplementation(gLS);
m_pValidator=((DOMImplementationLS*)pImpl)createDOMBuilder(DOMImplementationLS::MODE_SYNCHRONOUS,0); 

 
// Problem code.
 m_pValidator-setFeature(XMLUni::fgXercesSchemaExternalSchemaLocation, 
pszSchemaPath);
 
// End code
 
psSchemaDir is a fully qualified schema path. (ie z:\schema\schema.xsd)
 
My goal is to ignore the xsi:noNamespaceSchemaLocation= attribute value 
in the XML file and to
use the value in the program (pszSchemaPath).  When the program executes 
to //Problem code it blows up.  
 
How can I set my schema path internally in the program to override the 
value in the XML file?
 
Thank you,
Mary

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using fgXercesSchemaExternalSchemaLocation to set a schema path.

[Michael Fuller]

On Tue, Feb 08, 2005 at 12:29:20PM -0500, [EMAIL PROTECTED] wrote:
  
 How can I set my schema path internally in the program to override the 
 value in the XML file?
  

This has been discussed in:
http://issues.apache.org/jira/browse/XERCESC-1309

The conclusion (courtesy Alberto) was that you can only do this by either
a) writing a custom entity resolver that loads your preferred schemas, or by
b) pre-loading the schemas you want to use.  See also:
http://marc.theaimsgroup.com/?l=xerces-c-devm=110320431019714w=2

[Unfortunately, this behavior is inconsistent with Xerces-J.
In Xerces-J, setExternalSchemaLocation()/setExternalNoNamespaceSchemaLocation()
override the schemaLocation/noNamespaceSchemaLocation in a document instance.
As discussed in http://xml.apache.org/xerces-j/properties.html, that is quite
consistent with the XML Schema Recommendation.  Therefore, if you were using
Xerces-J rather than Xerces-C you could just call the above methods or
set the appropriate SAX2 properties.  That doesn't work with Xerces-C:
you have to use a resolver or do preloading.

In contrast, it's questionable if the opposite position as implemented by 
Xerces-C
is right: the Xerces-C behavior is -- effectively -- based on the assumption 
that
there is one true schema for any given namespace or no-namespace.  From my 
reading
of xml-dev discussion over the years, I'd have to suggest that is generally
considered wrong: there are many different schemas that can be reasonably
used to validate a document instance at different points in its lifecycle
or its progression through a business process.  Allowing the program to use
fgXercesSchemaExternalSchemaLocation, etc. (like Xerces-J) to set the schema
instances to be applied at parse time seems to be far cleaner than pre-loading
or custom entity resolvers.]

Michael

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]