Hi all, There are a number of places where the parser has to interact with the file system (e.g., in resolving systemId's, schemaLocation hints and Strings supplied to our JAXP #parse methods.) To my knowledge, all of these situations are expecting a URI--possibly relative--rather than a filename.
Historically--at least in recent history--we've been more and more permissive in what we'll accept here. We can usually figure out, for instance, that "c:\myfile.xml" maps to file:///c/myfile.xml. But recently, there have been a deluge of reports that we can't handle filenames with spaces or other characters disallowed by the URI spec, or that non-ASCII characters can't be processed. It would be possible--in rrinciple--to keep on becoming more accomodating. It would make our code more complex, and for things like Chinese characters it isn't clear that that complexity wouldn't be rather substantial. Or, we could change course and decide to allow only true URI's to be used consistently, and restrict ourselves to making sure we can absolutize relative URI's correctly in whatever context they're given. What do people think? Is it too much to ask of applications to provide URI's rather than platform-dependent filenames? Do people think increasing the complexity of our stream-processing code is worth whatever convenience is gained? Is it acceptable that, by allowing filenames, we're violating the letter of many specifications and probably not aiding the cause of platform/parser independence, since we're being more permissive than other products are likely to be? All thoughts appreciated! Cheers, Neil Neil Graham XML Parser Development IBM Toronto Lab Phone: 905-413-3519, T/L 969-3519 E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
