From: David Lofquist (david.lofquist@nwa.com)
Date: Fri Nov 10 2000 - 15:19:18 EST
>
> <!DOCTYPE test_doc SYSTEM "complex.dtd">
>
> > When the URI-Reference to ENT is found in DTD, there will be a call
> > to the entity loader to fetch ENT with the URI computed from:
> > - the URL of DTD as found in the result returned by the previous
> > invocation to get DTD
> > - the URI-Reference for ENT stored in DTD
> >
> > So yes there is 2 call to the entity loader, and yes it's normal,
> > I assume you agree.
>
>
> > If yes, this is simply because libxml store more information
> > than you expected the simple hack in you entity loaded is to try
> > top call the existing default one and only add the prefix if this
> > failed.
>
>
While I am not philosophically opposed to hacks :), it seems that the
root issue is that Ken's xml document is "URI-less". Since the DTD
has a relative path, rather than an absolute path, a call to
xmlParseDocument
will not find the DTD unless it is in the current working directory, or
the "hack" entity loader is used.
A workaround is to modify context->directory to the DTD directory before a
call to xmlParseDocument(context) to be the path to the DTD file (in Ken's
case, "/dvl/fds/dtd/"). I think this works for DTDs on inter/intranets as
well. It also seems to fit in with the spec to allow the default base URI
be application-dependent.
Is this an exploitation of libxml or an undocumented feature? :)
Dave
---- Message from the list xml@rpmfind.net Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@rpmfind.net
This archive was generated by hypermail 2b29 : Fri Nov 10 2000 - 15:44:21 EST