OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook-apps] Base URI for result of transformation?

Hi Stefan,
I'm not sure I understand what you are asking for.  8^)

I don't think the stylesheet can insert xml:base attributes for content 
modules, because the stylesheet doesn't know from which directory any given 
piece of XML in the document comes from.  The parsing process takes place 
before the document is fed to the stylesheet, and it is the parsing process 
that assembles the complete XML document from modules.  The great leap 
forward with XIncludes over system entities is that an XInclude processor 
will insert xml:base attributes during parsing to keep track of the source 
file locations.

Nor can the stylesheet insert xml:base for the document as a whole, because 
the stylesheet doesn't know the path to the document.  The XSLT processor 
does, but it doesn't provide that information to the stylesheet.

Then the question is whether the stylesheet should pass through to the FO 
file any xml:base attributes that an XInclude processor added.  If that is 
what you meant, then that's a possibility, but I'd have to see an example 
to understand how that would work.  Currently if $keep.relative.image.uris 
is set to 0 then xml:base attributes from the XInclude processor are merged 
(resolved) by the stylesheet into the fileref path so they are all relative 
to the FO file, not the original XML module.

I took a look at the testdocs directory, and it seems that an xml:base 
wouldn't help there anyway.  For example, the testdocs/tests/figure.001.xml 
has a fileref="graphics/duck-small.eps", but there is no "graphics" 
directory under tests.  Rather, these files are meant to be processed by 
the Makefile from above in the testdocs directory with a command that 
processes the path "tests/figure.001.xml".  The graphics directory is under 
testdocs, so the relative path works there.  But that's perhaps an unusual 
setup, and not one I would generally recommend.

Bob Stayton
Sagehill Enterprises
DocBook Consulting

----- Original Message ----- 
From: "Stefan Seefeld" <seefeld@sympatico.ca>
To: <docbook-apps@lists.oasis-open.org>
Sent: Monday, August 07, 2006 8:31 AM
Subject: Re: [docbook-apps] Base URI for result of transformation?

> Bob Stayton wrote:
>> Hi Tony,
>> The general behavior in XML is that a relative URL is taken as relative
>> to the xml:base of the element containing the reference.  If there is no
>> xml:base attribute, then it is taken as relative to the document
>> containing the reference.  In the case of url('...') in an FO document,
>> then the XSL-FO processor takes it as relative to the location of the FO
>> document, not the XML source, for which it has no knowledge.
> Right. But doesn't that imply that the xml -> xsl-fo stylesheets need to
> inject xml:base attributes whereever relative URLs are used such that
> the xsl-fo processor can still find the involved files ?
>> If you aren't using XInclude and you are using fileref (not entityref),
>> then the DocBook FO stylesheet just copies the fileref out to the FO
>> file, and the XSL-FO processor has to deal with that path.  So if your
>> main document uses system entities to build its content from the
>> modules, then any filerefs are not altered as they are copied to the FO.
> FWIW, the documents being talked about here are all from the 
> docbook-testdocs
> package.
> Regards,
> Stefan
> -- 
>      ...ich hab' noch einen Koffer in Berlin...
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]