[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] FW: [[1454121] Path dirs repeated twice inimagedata urls]
This looks like the problem in Xerces reported last September - see below Date: Fri, 16 Sep 2005 12:08:33 +0300 From: Oxygen XML Editor support <support@oxygenxml.com> X-Accept-Language: en-us, en To: Bob Stayton <bobs@sagehill.net> Cc: Ron Catterall <ron@catterall.net> Subject: Re: Sorin: problems with xml:base in docbook xsl Hello, You are right, the XInclude processor does not generate the correct xml:base attributes. We will file a bug report on the Xerces parser bugzilla. Thank you, Sorin <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger http://www.oxygenxml.com/ Bob Stayton wrote: >Hi, >I'm responding to an issue raised by Ron Catterall regarding the >behavior of xml:base and the DocBook XSL stylesheets. I believe the >stylesheet's behavior is correct and the XInclude processor is in >error. The values of a relative xml:base attribute is taken as >relative to the xml:base attributes of the elements in its ancestor >list. <book xmlns:xi="http://www.w3.org/2001/XInclude"; id="bookid" >lang="EN"> > <title> The Book Title</title> > <part id="Part_appendices" lang="EN" xml:base="level1/file1.xml"> > <title> Appendices</title> > <appendix id="file2id" lang="EN" xml:base="level1/level2/file2.xml"> > > The appendix element appears inside the part element, and so the >appendix xml:base attribute generated by the XInclude processor >should have been "level2/file2.xml", because the "level1" is implied >by the fact that appendix is contained inside part which has its own >xml:base. This means the XInclude processor in Oxygen is not >generating the correct xml:base attributes that match the nesting of >the elements in the resulting document. The xsltproc processor had >similar problems until they were reported and fixed. See the XML >Base W3C standard (section 4.3) to confirm what I'm saying: > http://www.w3.org/TR/xmlbase/ > Bob Stayton >Sagehill Enterprises >DocBook Consulting >bobs@sagehill.net <mailto:bobs@sagehill.net> > > ----- Original Message ----- > *From:* Ron Catterall <mailto:ron@catterall.net> > *To:* bobs@sagehill.net <mailto:bobs@sagehill.net> > *Sent:* Thursday, September 15, 2005 2:13 PM > *Subject:* problems with docbook xsl and the docbook-apps mailing list > > I have a docbook problem. Sorin at Oxygenxml support assures me it > is a bug in docbook xsl (the latest current release with docbook > 4.4, XSL: $Id: docbook.xsl,v 1.4 2005/04/12 08:23:16 radu_pisoi > Exp $ > ) > Sorin writes: > "I could reproduce the described behavior and it is a bug in the > DocBook XSL stylesheets about handling the xml:base attribute." > See below for the tests he ran. > > >> I'm having a problem with loss of images after transformation - >> HTML, XHTML or FO. Simple example files are in the attached >> gzipped tar file. I have located copies of image files where they >> ought to be for the fileref= - see attached files. >> >> When I transform (Docbook HTML, XHTML or PDP scenarios), all goes >> well and I always get the transformation successful message and >> the document displays in the browser (Safari) OK except that the >> image is not included. The html and pdf files are created. >> >> I get the message from the activity window that the files: >> >>file:///Library/WebServer/Documents/_XML/level0/level1/level1/level2/images/image1.jpg >> file:///Library/WebServer/Documents/_XML/level0/ld-d0e13.html >> do not exist. >> >> Where does the duplication /level1/level1/ come from? It looks >> like a typical user error, but I can't see it - see the source >> files in the attached file. The HTML file produced does have the >> /level1/level1/ in it: <img >> src="level1/level1/level2/images/image1.jpg - this is also in the >> attached tar >> >> The file >> /Library/WebServer/Documents/_XML/level0/level1/level2/images/image1.jpg >> DOES exist - see attached files. > > > I submitted this to support at Oxygenxml and got the following response: > > Hello, > > I could reproduce the described behavior and it is a bug in the > DocBook XSL stylesheets about handling the xml:base attribute. You > can check it by transforming file0.xml with a copy stylesheet like > below: > > <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; > version="1.0"> > <xsl:template match="node() | @*"> > <xsl:copy> > <xsl:apply-templates select="node() | @*"/> > </xsl:copy> > </xsl:template> > </xsl:stylesheet> > > It will resolve the XInclude references and create a single > document. This is the real transformed document. It has correct > references to the images but transforming it with the Docbook HTML > scenario in <oXygen/> that is the Docbook stylesheet for html output > ([oXygen-install-dir]/frameworks/docbook/xsl/html/docbook.xsl) will > create the reference > > <img src="level1/level1/level2/images/image1.jpg" ... > > instead of > > <img src="level1/level2/images/image1.jpg" ... > > If you do the same for file1.xml it will create correct references > and the transform works as it is expected. The same behavior happens > with both Saxon and Xalan transformers. So it is a problem in the > Docbook XSL stylesheet and it happens when the imagedata element has > 2 or more ancestors with a xml:base attribute. I attached the single > document created by the copy stylesheet. You should post it to the > docbook-apps list and ask that the maintainers of the Docbook XSL > stylesheets will fix the problem: > http://lists.oasis-open.org/archives/docbook-apps/ > I hope that helps, > Sorin > > <?xml version="1.0" encoding="utf-8"?> > <book xmlns:xi="http://www.w3.org/2001/XInclude"; id="bookid" lang="EN"> > <title> The Book Title</title> > <part id="Part_appendices" lang="EN" xml:base="level1/file1.xml"> > <title> Appendices</title> > <appendix id="file2id" lang="EN" > xml:base="level1/level2/file2.xml"> > <title> Title for file2</title> > <figure id="fig1id" float="0"> > <title> title for fig. 1</title> > <mediaobject> > <imageobject role="xhml"> > <imagedata fileref="images/image1.jpg" > format="JPG" width="350px" > contentwidth="283px" align="center"/> > </imageobject> > <imageobject role="fo"> > <imagedata fileref="images/image2.jpg" > format="JPG" width="11.0cm" > contentwidth="9.98cm" align="center"/> > </imageobject> > <textobject> > <phrase> The Figure 1 phrase</phrase> > </textobject> > <textobject id="figs"> > <formalpara> > <title> Fig. 1 textobject title</title> > <para> some text here </para> > </formalpara> > </textobject> > <caption> > <para> a caption</para> > </caption> > </mediaobject> > </figure> > </appendix> > </part> > </book> > > ---------------------------------------------------- > test files attached > ---------------------------------------------------- > > I'm using Oxygen 6.1(Docbook 4.4, XSL: $Id: docbook.xsl,v 1.4 > 2005/04/12 08:23:16 radu_pisoi Exp $ > ) on a Mac G4 server (MacOS 10.3.9 Server) > > Hope you can help in any way. > > Ron > >-- > > Ron Catterall, Phd, DSc email: ron@catterall.net > Prolongacion de Hidalgo 140 > http://catterall.net/ > San Felipe del Agua tel: +52 > 951 520 1821 > Oaxaca 68020 Mexico fax: +1 530 348 8309 >Bob Stayton <bobs@sagehill.net> writes: > > > Yes, I've seen this problem before. It usually happens when the >> xml:base attributes added by the XInclude processor are not >> correct. That is, the xml:base attributes should be taken as >> relative to the containing element. But XInclude processors seem >> to have a problem always getting them correct for all >> combinations of directory layouts and nested XIncludes. >> [...] >> This is best diagnosed by running an identity stylesheet using >> the XInclude processor and examining the xml:base attributes that >> it adds. If you keep track of the contexts and the nesting, you >> can usually figure out if the xml:base attributes are not >> correct. > >OK, I ran the source doc through an identity transform first using >xsltproc (libxml2) and then through Saxon (using the Xerces >XIncludeParserConfiguration class). At the end of this message is >a diff that shows the results. > >(I guess I should mention that the file and pathnames in the source >have embedded spaces. There are some places where the libxml2 >output has those a real spaces instead a URL-escaped ones.) > >But ignoring those differences in handling of the embedded spaces >(which shouldn't matter), looking at that diff, I see that the >Xerces XInclude implementation seems to be putting the wrong value >on the xml:base attribute of the chapter that contains the problem >"repeated path" (in the fileref value on an imagedata element). As >well as putting xml:base values on all the Xincluded sections in >the source -- while libxml2 puts no xml:base on those at all. > >And the Xerces implementation is also putting an empty value on >the xmlns:xi attribute... > >So, the cause of the problem that Mark is seeing does seem to be >bugginess in that Xerces Xinclude class. > >Is there any way that he might be able to work around it? By >adding or modifying xml:base attributes explictly set in his >source? > > --Mike > >--- libxml2-OUT.xml 2006-03-20 13:45:56.204747744 +0900 >+++ Xerces-OUT.xml 2006-03-20 13:45:03.167810584 +0900 >@@ -1,15 +1,14 @@ >-<?xml version="1.0"?> >-<book> >+<?xml version="1.0" encoding="utf-8"?><book> > <title>Drools Manual</title> > >- <part xml:base="Part - 1/part 1.xml"> >+ <part xml:base="Part%20-%201/part%201.xml"> > <title>dfsw</title> > >- <chapter xmlns:xi="http://www.w3.org/2003/XInclude"; >xml:base="Chapter - Rule Engine/Chapter - Rule Engine.xml"> >+ <chapter xmlns:xi="" >xml:base="Part%20-%201/Chapter%20-%20Rule%20Engine/Chapter%20-%20Rule%20Engine.xml"> > <title>The Rule Engine</title> > > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Engine/Section%20-%20What%20is%20a%20Rule%20Engine.xml"> > <title>What is a Rule Engine</title> > > <para>At the simplest level a <indexterm> >@@ -137,7 +136,7 @@ > </indexterm>Activations.</para> > </section> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Engine/Section%20-%20Why%20use%20a%20Rule%20Engine.xml"> > <title>Why use a Rule Engine</title> > > <para>Two questions often asked are</para> >@@ -187,17 +186,17 @@ > </itemizedlist> > </section> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Engine/Section%20-%20Rete%20Algorithm.xml"> > <title>Rete Algorithm</title> > </section> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Engine/Section%20-%20Rule%20Base.xml"> > <title>Rule Base</title> > > <para>uuuere</para> > </section> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Engine/Section%20-%20Working%20Memory.xml"> > <title>WorkingMemory</title> > > <para>uuuere</para> >@@ -251,7 +250,7 @@ > </section> > </section> > >- <section> >+ <section xml:base="Chapter%20-%20Rule%20Engine/Section%20-%20Agenda.xml"> > <title>Agenda</title> > > <para>uuuere</para> >@@ -275,7 +274,7 @@ > </section> > </section> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Engine/Section%20-%20Event%20Model.xml"> > <title>Event Model</title> > > <para>uuuere</para> >@@ -294,10 +293,10 @@ > </section> > </chapter> > >- <chapter xmlns:xi="http://www.w3.org/2003/XInclude"; >xml:base="Chapter - Rule Language/Chapter - Rule Language.xml"> >+ <chapter xmlns:xi="" >xml:base="Part%20-%201/Chapter%20-%20Rule%20Language/Chapter%20-%20Rule%20Language.xml"> > <title>The Rule Language</title> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Language/Section%20-%20Package.xml"> > <title>Package</title> > > <para>uuuere</para> >@@ -321,25 +320,25 @@ > </section> > </section> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Language/Section%20-%20Function.xml"> > <title>Function</title> > > <para>uuuere</para> > </section> > >- <section> >+ <section xml:base="Chapter%20-%20Rule%20Language/Section%20-%20Rule.xml"> > <title>Rule</title> > > <para>uuuere</para> > </section> > >- <section> >+ <section xml:base="Chapter%20-%20Rule%20Language/Section%20-%20Query.xml"> > <title>Query</title> > > <para>uuuere</para> > </section> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Language/Section%20-%20Field%20Constraints.xml"> > <title>Field Constraints</title> > > <para>uuuere</para> >@@ -363,7 +362,7 @@ > </section> > </section> > >- <section> >+ <section >xml:base="Chapter%20-%20Rule%20Language/Section%20-%20Conditional%20Elements.xml"> > <title>Conditional Elements</title> > > <para>uuuere</para> >@@ -402,4 +401,4 @@ > </part> > > <index/> >-</book> >+</book> > >Attachment converted: Server HD 5:smime 5.p7s ( / ) (00361BC3) -- Ron Catterall, Phd, DSc email: ron@catterall.net Prolongacion de Hidalgo 140 http://catterall.net/ San Felipe del Agua tel: +52 951 520 1821 Oaxaca 68020 Mexico fax: +1 530 348 8309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]