Should have said: the point here is to avoid manipulating the schemaLocation value at all. If it works, this approach should be robust and reasonably portable.
> -----Original Message----- > From: Jesse Pelton [mailto:[EMAIL PROTECTED] > Sent: Monday, May 23, 2005 10:54 AM > To: [EMAIL PROTECTED]; [email protected] > Subject: RE: Handling of schemaLocation attribute > > Wow. Troublesome relatives! I don't have any experience in > this area, > so this may be a bone-headed idea, but can you extract the document's > directory and set the current working directory to that > before parsing? > I haven't analyzed the code exhaustively, but in a quick search, it > looks like Xerces never sets the current directory. That > would explain > why relative paths are relative to the executable directory - that's > typically the initial working directory. > > > -----Original Message----- > > From: Elisha Berns [mailto:[EMAIL PROTECTED] > > Sent: Monday, May 23, 2005 10:31 AM > > To: Jesse Pelton; [email protected] > > Subject: RE: Handling of schemaLocation attribute > > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
