I don't think Saxon itself supports XIncludes. Saxon uses the Xerces parser
with the XInclude function turned on:
http://www.saxonica.com/documentation/sourcedocs/controlling-parsing.html
The XInclude spec says that xml:base attributes must be relative to the
closest ancestor xml:base. I'm pretty sure that is how Saxon 6 behaves. If
Saxon9 is generating xml:base attributes always relative to the top level,
then that is not what the XInclude spec says, nor what the DocBook
stylesheet expects.
Bob Stayton
Sagehill Enterprises
[email protected]
--------------------------------------------------
From: "Alexey Neyman" <[email protected]>
Sent: Tuesday, May 14, 2013 10:25 AM
To: <[email protected]>
Cc: "Bob Stayton" <[email protected]>; "Lars Vogel" <[email protected]>
Subject: Re: [docbook-apps] WARNING: cannot add @xml:base to node set root
element. Relative paths may not work.
Hi Lars, Bob,
Just one point: xsltproc does xml:base fixup on nodesets included through
XInclude, so inside the document there are xml:base elements added
properly.
However, Bob's point still stands: if the top-level document is in
non-current
directory, it will break the external references.
Speaking of Saxon, I am not sure if it does xml:base fixup properly on
XIncluded modular documents from different directories. Originally, I was
investigating a bug in libxml2 regarding xml:base fixup (pushed to master,
will be in the next release), but I also tried Saxon. Here is a link to
the
thread on libxml2 mailing list (which has a small test case attached):
https://mail.gnome.org/archives/xml/2013-April/msg00024.html
In brief, Saxon seems to emit xml:base relative to top-level document
rather
than to the most recent point of inclusion. DocBook stylesheets (at least,
1.78.0 that I used) assume the location relative to the base of the
including
nodeset. xsltproc conforms to the expectations of DocBook stylesheets, and
as
far as I understand, to the XInclude specification.
Regards,
Alexey.
On Tuesday, May 14, 2013 09:01:37 am Bob Stayton wrote:
Hi Lars,
You should get that message only when two conditions are met:
1. You are processing a DocBook 5 document with the non-namespaced
stylesheets. or
You are single-step profiling by using profile-docbook.xsl (probably
your case).
and
2. You are using xsltproc (which lacks an extension function to get the
name of the current directory).
With either condition in (1), the document is preprocessed into an
internal
nodeset (a nodeset held in memory) before being processed by the
stylesheets. The internal nodeset loses all contact with the filesystem
where the files originated, so the preprocessing template tries to add
relative directory references into the internal nodeset by adding
xml:base
attributes to preserve the relative locations. It uses an extension
function to get the original base directory of the document, but xsltproc
does not have a function to fetch that information, while Saxon and Xalan
do.
So if you use modular doc and the modules are in various directories,
that
directory structure information gets lost in the internal subset. If
your documents don't need such xml:base attributes, then it has no effect
on your output.
You can avoid it by either using Saxon, or by using two-step profiling.
Bob Stayton
Sagehill Enterprises
[email protected]
From: Lars Vogel
Sent: Tuesday, May 14, 2013 7:13 AM
To: DocBook Apps
Subject: [docbook-apps] WARNING: cannot add @xml:base to node set root
element. Relative paths may not work.
Hello,
since a while I get the following warning during the transformation with
the docbook distribution:
WARNING: cannot add @xml:base to node set root element. Relative paths
may
not work.
I'm not sure what triggers this warning, a Google search resulted in
hints
about Docbook V5.0 but I'm still using Docbook 4.5.
I'm currently using the docbook-xsl-1.77.1 distribution and I think (but
I'm not sure) that I have this warning since I upgraded from 1.76. The
output looks ok to me, but this warning does not create a warm fussy
feeling. ;-)
Any hint how to get rid of this warning?
Best regards, Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
