You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xerces.apache.org by Jason Rizer <ja...@yahoo.com> on 2001/04/19 05:11:08 UTC
One more quick DTD question
Hello. One more quick DTD question: Where exactly
does the parser look for the specified DTD. Current
Directory? Classpath? Somewhere else? Sorry to be a
bother.
Blue Skies
-Jason
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: One more quick DTD question
Posted by "John L. Utz III" <ut...@singingfish.com>.
On Thu, 19 Apr 2001, Andy Clark wrote:
> Jason Rizer wrote:
> > Hello. One more quick DTD question: Where exactly
> > does the parser look for the specified DTD. Current
> > Directory? Classpath? Somewhere else? Sorry to be a
> > bother.
>
> If the system identifier is relative, then the DTD entity
> (or other external parsed entity) will be located relative
> to where it's referenced. In other words, if the document
> is "file:///c:/docs/document.xml" and the DTD is specified
> as "grammar.dtd", then the parser will look for the DTD at
> "file:///c:/docs/grammar.dtd".
but it's not guaranteed to be in said directory. it's possible to have a
relative path reference to somewhere else on the same filesystem:
<!-- Note relative pathname to dtd. utz 010315 -->
<!DOCTYPE cpp SYSTEM "../../dtd/cpp.dtd">
<cpp partnerName="Blastro">
.......
( works great at my house! :-) )
so, the point being that a dtd is not guaranteed to be in a particular
location. Arguments can be made for a central 'blessed' dtd or for
copying it into each and every data directory. the choice is up to
somebody and it isnt always going to be you.
> This is an important point because a lot of people forget
> to set the systemId when using an InputSource -- most
> frequently in a custom EntityResolver that they've written
> but it can also be because of calling parse(InputSource).
> And without the systemId, the parser has no idea where to
> look for the entity! If it's not relative to the working
> directory of the Java program, then it will fail.
so this means that if you are trying to write code that evaluates what you
plan to do based on the dtd, you had either:
1. forced the dtd to be where your code expects it ( lucky u! u got to
make the choice! )
2. use the cleverness alluded to previously to get the dtd name from the
parser. ( i feel that this is the best way, but i think there is a
chicken and egg problem that i may not be fully understanding )
3. do a File::Find (to use a perl-ism) and hope that it's the only dtd in
the neigborhood. or that if it's not the only dtd, you have a mechanism
for disambiguating it...
> --
> Andy Clark * IBM, TRL - Japan * andyc@apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-j-user-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org
Re: One more quick DTD question
Posted by Andy Clark <an...@apache.org>.
Jason Rizer wrote:
> Hello. One more quick DTD question: Where exactly
> does the parser look for the specified DTD. Current
> Directory? Classpath? Somewhere else? Sorry to be a
> bother.
If the system identifier is relative, then the DTD entity
(or other external parsed entity) will be located relative
to where it's referenced. In other words, if the document
is "file:///c:/docs/document.xml" and the DTD is specified
as "grammar.dtd", then the parser will look for the DTD at
"file:///c:/docs/grammar.dtd".
This is an important point because a lot of people forget
to set the systemId when using an InputSource -- most
frequently in a custom EntityResolver that they've written
but it can also be because of calling parse(InputSource).
And without the systemId, the parser has no idea where to
look for the entity! If it's not relative to the working
directory of the Java program, then it will fail.
--
Andy Clark * IBM, TRL - Japan * andyc@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-user-help@xml.apache.org