Thanks for the really clear answers. By the way, the issue of invalid URIs came up because the documents I need to parse have schemaLocation attributes with filenames that start with './' such as './Test.xsd'. So the URI was formally correct, but because the file (xml and xsd) does not reside in the current working directory where the program is running I have to expand the URI just to get the valid path to it.
A simple expansion using Xerces XMLPlatformUtils::getFullPath( relative_path_to_xsd_file ) will create an invalid path due to the file not residing in the current working directory, rather in a directory relative to the location of the host xml file. And consequently the xml file cannot be validated because the contents of schemaLocation cannot be processed correctly. So to make this work I make a call to: XMLCh const* szXsdFile = XMLPlatformUtils::weavePaths(base_path_of_xml_file, relative_path_of_xsd_file); to get the full path to the xsd file. Then I recreate the schemaLocation string with the 'massaged' path and call: reader.setProperty(XMLUni::fgXercesSchemaExternalSchemaLocation, szLocation); So really it's here that any whitespace in the path statements need to be encoded, not the initial URI. So is there a simple library call, somewhere, in some library, that will fix up the whitespace in filenames as required? But this is so round-about, what's the alternative to fixing each relative path to a fully qualified path just so Xerces can actually find the xsd file(s)? This simple assumption used (in Xerces) that ./ is relative to the current working directory, and not the directory of the xml file itself, begs the question if this works as intended, or is it a bug? Thanks, Elisha Berns > -----Original Message----- > From: Jesse Pelton [mailto:[EMAIL PROTECTED] > Sent: Monday, May 23, 2005 5:22 AM > To: [email protected]; [EMAIL PROTECTED] > Subject: RE: Handling of schemaLocation attribute > > Whitespace is illegal in URIs; it needs to be percent-encoded if > present. See http://www.faqs.org/rfcs/rfc3986.html. Odds are good that > you'll need additional massaging to transform a file path to a URI, such > as prepending file:/// and converting backslashes to forward slashes. > RFC 3986 is the authority, though it is regrettably vague on filesystem > URIs. > > Xerces may allow you to get away with strings that are technically not > URIs. If so, it's up to you to decide whether interoperability with > other Oses and/or parsers is important. If it is, make your URIs valid. > > > -----Original Message----- > > From: Elisha Berns [mailto:[EMAIL PROTECTED] > > Sent: Sunday, May 22, 2005 9:41 PM > > To: Xerces C++ Development > > Subject: Handling of schemaLocation attribute > > > > Does the handling of schemaLocation have a bug or a feature in Xerces > > 2.6? > > > > The schemaLocation attribute whose value syntax is pairs of namespace > > names/xsd file locations only works correctly when there are no space > > characters in the xsd file location. Is this a bug or a feature? > > > > Under Win32 I can't predict or count on when the full path to the xsd > > filename will have space characters so something seems broken here. > > > > I experimented with adding either single or double quotes around the > > full path to the xsd file, but that doesn't work either. > > > > What am I missing about how to use schemaLocation and also: > > > > reader.setProperty(XMLUni::fgXercesSchemaExternalSchemaLocation, ( > > void*)strLocation.c_str()); > > > > works the same way. > > > > Thanks, > > > > Elisha Berns > > [EMAIL PROTECTED] > > tel. (310) 556 - 8332 > > fax (310) 556 - 2839 > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
