file://d:/a/b/c.dtd isn't a valid URL.
Section 3.10 of RFC 1738 [ http://www.faqs.org/rfcs/rfc1738.html ]: A file URL takes the form: file://<host>/<path> where <host> is the fully qualified domain name of the system on which the <path> is accessible, and <path> is a hierarchical directory path of the form <directory>/<directory>/.../<name>. [snip] As a special case, <host> can be the string "localhost" or the empty string; this is interpreted as `the machine from which the URL is being interpreted'. By specifying file://d:/a/b/c.dtd, you are specifing that "d:" is the host rather than part of the actual file path. Add an extra / in there, and things should work ok: file:///d:/a/b/c.dtd in this case the "empty string" between the second and third / implies the file is on the local host. regards, michael > -----Original Message----- > From: Tal Dayan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, November 13, 2001 10:00 PM > To: Jakarta Commons Developers List > Subject: RE: [digester] using non URL'ed DTD's > > > Hello, > > We are still not able to use a DTD for validation because our > DTD file has a > path that > is not acceptable by Digester and/or the underlying XML > parser (the URL is > 'file://d:/a/b/c.dtd' but the Windows drive letter 'd:' confuses > everything). Actually, this is a more general issue in cases > where the DTD > can not be referred to by a URL (e.g., when it is taken > directly from a data > base). > > My suggestion is to add another registration method that > accepts a Reader > instead of the URL. This way the DTD can be retrieved from > file, in memory > cache buffer, etc. > > Thanks, > > Tal > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
