Re: [docbook-apps] Olinking and Chunked HTML Transformations

["Bob Stayton" <bobs@sagehill.net>]



Hi Ray,

I'm getting a little confused.  You raised two different issues in your original mail.

 

1.  The hrefs being generated in your chunked output were of the form #id and did not contain the html filename.

 

2.  The olinkdb.xml file doesn't validate against common/targetdatabase.dtd.

 

I presume that your first response about commenting out all customizations was about your hrefs still being only of the #id form.  What happens when you process your document with the original DocBook html/chunk.xsl stylesheet?  Also, what does the target.db data have for the hrefs (if you are using olinks instead of xrefs)?  The target.db should have the html filenames as well as the #id part.  If not, then the problem is on the collection side, which must be done with the same stylehsheet processing the output.

 

Regarding the second item, it is actually the DTD that needs fixing.  The elements containing text have a content model of (#PCDATA), when they should all be ANY because there is no telling what kind of markup might be used in the text.  You might try changing a copy of the DTD to use ANY and see if validates then.

 

Bob Stayton
Sagehill Enterprises
DocBook Consulting
bobs@sagehill.net

 

 

----- Original Message -----

From: Ray Miller

To: docbook-apps@lists.oasis-open.org

Cc: oxygen-user@oxygenxml.com

Sent: Monday, May 01, 2006 8:40 AM

Subject: RE: [docbook-apps] Olinking and Chunked HTML Transformations

>> Yes, it should, and it does why I test it with the html/chunk.xsl stylesheet.  Are you using a customization layer with the chunking stylesheet?  If so, you have to construct it carefully to get the import sequence right.  If you don't, then you get a mix of chunked and non-chunked behavior, and I suspect that is what happened in your target.db file.  See: 

http://www.sagehill.net/docbookxsl/ChunkingCustomization.html 

If you were following those guidelines, then something else is going on that will require more information. <<

 

 

Commented out all customizations; issues unchanged.

 

For some yet unknown reason when utilizing oXygen (eclipse plugin) on the Linux side, the extended characters €œ<text>€� to not appear surrounding the section text of <xreftext>, Windows side only; will resolve on the oXygen list. Using UTF-8 encoding.

 

The <i> tags persist at the chapter <xref> sections surrounding chapter text.

 

Also <span class="trademark"/> appears in the map within the <ttl> element (just began using the trademark element in a section element).

 

Lastly, when the aforementioned tags are deleted, the olinkdb.xml map validates on the Linux side and subsequent HTML transformations behave as expected. From the Windows side, validation complains “Invalid byte 1 of 1-byte UTF-8 sequence.” Again, this issue is probably best addressed on the oXygen list but any help would be appreciated.

 

Using docbook-rng-5.0b5, docbook-xsl-snapshot (4/30/06), oxygen-7.1.0 (eclipse-3.1.2 plugin), saxon-6.5.5

 

 

Ray