Well, my theory was that since Xerces does not set the current working directory, you could do so. If you set it to the (presumably known) location of the document that you're parsing, the schemaLocation path would then be relative to the document directory, which is what you want if I understand you correctly. In that case, you wouldn't have to rewrite the schemaLocation.
A little research indicates that this won't work in a multi-threaded Win32 environment (unless all your documents are guaranteed to be in a single directory). According to the MSDN documentation for SetCurrentDirectory(), "Each process has a single current directory," so different threads can't have different current working directories. To address your question directly: I suspect the answer is that Xerces' use of relative paths is accidental (unspecified). If I'm right, it's neither a bug nor a feature, but an undefined behavior, in which case it might be a good idea to define its behavior. Whether that's possible to do in a robust cross-platform way I have no idea. > -----Original Message----- > From: Elisha Berns [mailto:[EMAIL PROTECTED] > Sent: Monday, May 23, 2005 3:26 PM > To: [email protected] > Subject: RE: Handling of schemaLocation attribute > > This is really my question at this point: > > Is Xerces' interpretation/use of relative paths inside the > schemaLocation attribute intentional (a feature) or > accidental (a bug)? > And the same would be the question for other attributes and elements > that may take relative paths: > > noNamespaceSchemaLocation > <import> > <include> > > I don't see how not to change the schemaLocation string since the > relative path needs to be expanded, and as has been pointed out, and > correctly formed as a URI. Any other thoughts? > > Thanks, > > Elisha > > > 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]
