I've experienced this issue also. The worst part is having to contuinually
explain this to all the content editors / producers who complain "but
XmlSpy (or XMetal) says these documents are valid!"
:^)
"Aleksandar
Milanovic" To: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED] cc:
sinc.com> Subject: RE: filenames versus
URI's
09/10/2002 02:26
PM
Please respond to
xerces-j-user
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
