I agree with the strict approach. It makes one aware that there is a problem, and that is especially important for XML documents that must be parsed and validated by possibly different XML parsers.
Take the example of XML Spy, which is a great XML editor, but it is very very flexible WRT the adherence of an XML document to its schema. It lets you use Windows specific paths in schema locations, and numerous other XML Schema invalid things. This is all nice while you're editing, but when you try to use the XML document and schemas in a s/w application, which uses a different XML parser/validator, you're faced with zillion validation errors. Cheers, Alex -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: September 10, 2002 10:50 AM To: [EMAIL PROTECTED] Subject: Re: filenames versus URI's I'd say become strict. By being accomidating you are encouraging people to write code that may not be portable to other JAXP compliant parsers...and setting them up for unexpected problems later. It shouldn't be that big a deal for users to change their code to use Java's URI or URL classes to properly urify the filename--just provide them with a couple of examples. Eric [EMAIL PROTECTED] To: [EMAIL PROTECTED], [email protected] 09/10/2002 12:10 cc: PM Subject: filenames versus URI's Please respond to xerces-j-user 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] --------------------------------------------------------------------- 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]
