This is the mail archive of the docbook-apps@lists.oasis-open.org mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: file path peculiarity with xinclude


Now this *is* peculiar.  I tried altering my entities file as you suggest -
declaring the entities relative to the location of the entities file, which
actually makes much more sense, and is much more useful for reusing the
entities file! Them I ran xmllint --debug on an individual document, and
everything worked fine.  The resolved URI's in the output were the actual
locations of the files.  However, I tried transforming the doc with Xalan -
my usual tool - and it appeared to be looking for the files relative to the
including document, not the entities file (ie the way I had specified it
originally, because it worked with Xalan).  It's really very odd.  Has
anyone else had relative URI weirdosity with Xalan/Xerces?  I have Xalan
version 2.4.1.

I could switch to using xsltproc for my transformations, except it throws
the following error if I use it with documents that have mediaobjects in
them:

Error /usr/src/package/libxml2-2.4.17/xpath.c:8247: Undefined namespace
prefix
xmlXPathCompiledEval: evaluation failed

<sighs>

-----Original Message-----
OK, now I think I understand what is going on.
It doesn't have anything to do with Xinclude per se,
because I can duplicate this behavior using only
system entity references.

The relevant section in the XML specification (4.2.2
External Entities) says:

"... relative URIs are relative to the location of the resource
within which the entity declaration occurs."

In this case, your document header says:

<!ENTITY % myents SYSTEM "../../common/foobarents.ent">
%myents;

And foobarents.ent contains:

<!ENTITY foo SYSTEM "../../common/foo.xml">

When the XML parser see &foo; it takes the latter reference as
relative to the location of the former reference where
the foo entity is declared,
so you get a total path of:

../../common/../../common/foo.xml

which resolves to:

../../../common/foo.xml

The solution is to use this in foobarents.ent:

<!ENTITY foo SYSTEM "foo.xml">

(if foo.xml is in the same directory as foobarents.ent).


What I don't understand is where you said your paths worked
for individual documents.  This arrangement fails for me:

Individual document:

<?xml version="1.0"?>
<!DOCTYPE book SYSTEM "docbook42/docbookx.dtd" [
<!ENTITY % myents SYSTEM "../../common/foobarents.ent">
%myents;
]>
<book><title>foo</title>
&foo;
</book>


And ../../common/foobarents.ent contains:

<!ENTITY foo SYSTEM "../../common/foo.xml">

and foo.xml is located in ../../common.
I get the same error about not being able to load
../../../foo.xml when I process this individual
document.  I get a similar error with both
xsltproc and Saxon.

If you run xmllint --debug on the individual document,
it will show these lines:

    ENTITY_REF(foo)
      EXTERNAL_GENERAL_PARSED_ENTITY foo
      SystemID=../../common/foo.xml
      URI=../../../common/foo.xml

This shows now it converts the SystemID it finds
in foobarents.ent to a URI that is relative
to the location of foobarents.ent.

So I'm curious about
what kind of references you put in your individual
documents that got it to work with this arrangement?


Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: bobs@sco.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]