docbook-apps

I am looking to include a file in my docbook document, but I don't want
to generate xml:base. Is there a way to do this ??
I know "keep.relative.image.uris" can be used. But I am not using
images. I need to include a text/xml file.

Hi,

On Montag, 3. März 2008, Mansour wrote:
> I am looking to include a file in my docbook document, but I don't want
> to generate xml:base. Is there a way to do this ??
> I know "keep.relative.image.uris" can be used. But I am not using
> images. I need to include a text/xml file.

I am not sure what you want to achieve, so maybe some background
information might be useful:

According to the XInclude specification[1], "each element information item
in the top-level included items which has a different base URI than its
include parent has an attribute information item added to its attributes
property. [see 4.5.5 Base URI Fixup]" (which is in fact the xml:base
attribute).

There *may* be an option in your XML parser or XInclude processor,
because "An XInclude processor may, at user option, suppress xml:base
and/or xml:lang fixup." [see 4.5 Creating the Result Infoset] So you
should check the available options.

If there is no option, I fear, the only method is to post process your
document with an XSLT stylesheet. You have to copy every element,
attribute, comment and processing instruction node except xml:base. I
don't think, this is a good idea. Normally, xml:base isn't harmful.


Hope it was a bit helpful. :)


Bye,
Tom

-------
[1] http://www.w3.org/TR/xinclude/


--
Thomas Schraitle

Thomas, I am having some problems with the generated xml:base, so yes,
it my case it's harmful. The issue is, I have a directory hierarchy like
this:
book/chapter/section/images

In each directory there's a docbook file to be included in the upper
level document. So, I have in section1.xml and XInclude with a
reference to images/image1.svg, now the issue is the final generated
"FO" has xml:base "section/images" only. The first two are gone. When I
generate pdf using fop I get an error about not finding the given file.
I don't know how to explain this, but this is the case with xsltproc and
with xalan-j ! this is what really confusing me.

I am including the whole SVG graphic file in my documents so there's no
need for xml:base attribute especially if it's behaving this way. I
looked around for a way to disable this attribute but couldn't find.

My way around was a little bit weired. Since I am generating the SVG
graphics from an xml files. I included the xml file and added a template
to process it in my customization layer. This way it's not relying on an
external graphics file but definitely it takes longer to compile the
document. So it's working for me, but the original issue is not
resolved, which is, the wrong xml:base attribute.


Thomas Schraitle wrote:
> Hi,
>
> On Montag, 3. März 2008, Mansour wrote:
>
>> I am looking to include a file in my docbook document, but I don't want
>> to generate xml:base. Is there a way to do this ??
>> I know "keep.relative.image.uris" can be used. But I am not using
>> images. I need to include a text/xml file.
>>
>
> I am not sure what you want to achieve, so maybe some background
> information might be useful:
>
> According to the XInclude specification[1], "each element information item
> in the top-level included items which has a different base URI than its
> include parent has an attribute information item added to its attributes
> property. [see 4.5.5 Base URI Fixup]" (which is in fact the xml:base
> attribute).
>
> There *may* be an option in your XML parser or XInclude processor,
> because "An XInclude processor may, at user option, suppress xml:base
> and/or xml:lang fixup." [see 4.5 Creating the Result Infoset] So you
> should check the available options.
>
> If there is no option, I fear, the only method is to post process your
> document with an XSLT stylesheet. You have to copy every element,
> attribute, comment and processing instruction node except xml:base. I
> don't think, this is a good idea. Normally, xml:base isn't harmful.
>
>
> Hope it was a bit helpful. :)
>
>
> Bye,
> Tom
>
> -------
> [1] http://www.w3.org/TR/xinclude/
>
>
>

Hi,

sorry for the late answer, but I was busy with other things.

On Mittwoch, 5. März 2008, Mansour wrote:
> Thomas, I am having some problems with the generated xml:base, so yes,
> it my case it's harmful. The issue is, I have a directory hierarchy
> like this:
> book/chapter/section/images
>
> In each directory there's a docbook file to be included in the upper
> level document. So, I have in section1.xml and XInclude with a
> reference to images/image1.svg, now the issue is the final generated
> "FO" has xml:base "section/images" only.

Do I understood it right: The FO file contain xml:base attributes? Where
do they came from? I never saw this happen.


> [...]
>
> I am including the whole SVG graphic file in my documents so there's no
> need for xml:base attribute especially if it's behaving this way. I
> looked around for a way to disable this attribute but couldn't find.

That works for SVG, but obviously not with formats like JPEG, PNG, ... :)


> My way around was a little bit weired. Since I am generating the SVG
> graphics from an xml files. I included the xml file and added a
> template to process it in my customization layer. This way it's not
> relying on an external graphics file but definitely it takes longer to
> compile the document. So it's working for me, but the original issue is
> not resolved, which is, the wrong xml:base attribute.

Did you know the parameter "keep.relative.image.uris" and "img.src.path"
(omitted)? Cited from the webpage[1,2]:

If non-zero, relative URIs (in, for example fileref attributes) will
be used in the generated output. Otherwise, the URIs will be made
absolute with respect to the base URI.

Note that the stylesheets calculate (and use) the absolute form for
some purposes, this only applies to the resulting output.

Maybe you should try this first.


Tom

-------
[1]
http://docbook.sourceforge.net/release/xsl/current/doc/fo/keep.relative.image.uris.html
[2]
http://docbook.sourceforge.net/release/xsl/current/doc/fo/img.src.path.html

--
Thomas Schraitle

Thomas Schraitle wrote:

>> In each directory there's a docbook file to be included in the upper
>> level document. So, I have in section1.xml and XInclude with a
>> reference to images/image1.svg, now the issue is the final generated
>> "FO" has xml:base "section/images" only.
>
> Do I understood it right: The FO file contain xml:base attributes? Where
> do they came from? I never saw this happen.

If a.xml includes subdir/b.xml, the anchor node holding the b.xml
document inside the result set has to get xml:base="subdir/b.xml". It's
the xml processor (in this case, xslt processor) which has to do this.

(That is the paragraph you cited in your other mail.)

And more often than not, that's exactly what is broken. (xsltproc has
some bugs, and apparently saxon has, too)

Regards,
Stefan

--

...ich hab' noch einen Koffer in Berlin...

Hi,

On Freitag, 7. März 2008, Stefan Seefeld wrote:
> Thomas Schraitle wrote:
> >> In each directory there's a docbook file to be included in the upper
> >> level document. So, I have in section1.xml and XInclude with a
> >> reference to images/image1.svg, now the issue is the final generated
> >> "FO" has xml:base "section/images" only.
> >
> > Do I understood it right: The FO file contain xml:base attributes?
> > Where do they came from? I never saw this happen.
>
> If a.xml includes subdir/b.xml, the anchor node holding the b.xml
> document inside the result set has to get xml:base="subdir/b.xml". It's
> the xml processor (in this case, xslt processor) which has to do this.

Maybe I wasn't clear enough, but that was not my point. The *FO* shouldn't
get a xml:base, right? :)
For me, it looked like the original poster described a final FO file
containing a xml:base attribute (see above).


> And more often than not, that's exactly what is broken. (xsltproc has
> some bugs, and apparently saxon has, too)

Oh, I was not aware of this. It seems I never run into this problem
luckily. ;)


Thanks for clarification, Stefan.
Tom

--
Thomas Schraitle

Thomas Schraitle wrote:

>> If a.xml includes subdir/b.xml, the anchor node holding the b.xml
>> document inside the result set has to get xml:base="subdir/b.xml". It's
>> the xml processor (in this case, xslt processor) which has to do this.
>
> Maybe I wasn't clear enough, but that was not my point. The *FO* shouldn't
> get a xml:base, right? :)
> For me, it looked like the original poster described a final FO file
> containing a xml:base attribute (see above).

I only see two possibilities to deal with relative URLs: Either they get
explicitely adjusted by the fo generator, or they keep their original
value. In the latter case the xml:base attribute has to be preserved, or
the fo processor won't be able to locate the resources.

In the fo output I have looked at (generated with xsltproc /
docbook-xsl) the xml:base attribute is still present, albeit wrong in
certain cases.

Regards,
Stefan

--

...ich hab' noch einen Koffer in Berlin...

Thomas Schraitle wrote:

> There *may* be an option in your XML parser or XInclude processor,
> because "An XInclude processor may, at user option, suppress xml:base
> and/or xml:lang fixup." [see 4.5 Creating the Result Infoset] So you
> should check the available options.

Note, however, the 'may', in conjunction with 'suppress'.
By default a processor is expected to make sure relative URLs continue
to be valid (i.e. pointing to the same resource as prior to the inclusion).

This has to work with any XInclude processing, whether XSLT is involved
or not. I strongly believe the issue is with the XML / XSLT processor
doing the xinclusion. User intervention shouldn't be required.

Regards,
Stefan


--

...ich hab' noch einen Koffer in Berlin...