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] WARNING: cannot add @xml:base to node set root element. Relative paths may not work.


Thanks everyone for the reply. I'm not using Docbook 5 nor do I use profile-docbook.xsl. I'm also using saxon6.5.5 and the Docbook I'm processing is one big file which I preprocessed with an XInclude Ant tasks.

I will try to investigate further and if I find out more, I post this to the this group.

Thanks again everyone, Lars




2013/5/14 Alexey Neyman <stilor@att.net>
Indeed, I've just checked and Xerxes seems to have the same issue.

So, this is one caveat to keep in mind when processing modular DocBook
documents with Saxon/Xerxes.

Regards,
Alexey.

On Tuesday, May 14, 2013 12:00:50 pm Bob Stayton wrote:
> 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
> bobs@sagehill.net
>
> --------------------------------------------------
> From: "Alexey Neyman" <stilor@att.net>
> Sent: Tuesday, May 14, 2013 10:25 AM
> To: <docbook-apps@lists.oasis-open.org>
> Cc: "Bob Stayton" <bobs@sagehill.net>; "Lars Vogel" <lars.vogel@gmail.com>
> 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
> >> bobs@sagehill.net
> >>
> >>
> >> 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: 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]