Can anyone point me to the part of this file that controls chunking?
http://docbook4j.googlecode.com/svn-history/r4/trunk/docbook4j/src/main/resources/xsl/docbook/webhelp/xsl/webhelp-common.xsl
I can't relate what I find in this doc to the code I see in that file:
http://www.sagehill.net/docbookxsl/Chunking.html
I want to modify the XSL so that it chunks at <?confluence type="page" ?> instead of <section xml:id= ...>.
The main XSL stylesheet DocBook Webhelp uses is webhelp.xsl. This includes the webhelp-common.xsl, and imports the xhtml chunk.xsl. The chunking code is included in the chunk.xsl and the stylesheets it imports especially the chunk-common.xsl.
Related
I have to convert one xml to html page. I read that xml and mapped to transform xml. I have added html formatting tags in xslt. But it is not reflecting in page. I am getting data of xml in one line side by side. The html code not working what i have given. So any one can let me know how to transform xml to html, is there any other solution ?
yes, I have added that "tibco xslt " in title of this question ....
when working on tibco bw, I have to convert xml into html webpage; so i have used html code along with xslt transformation in xslt activity and also referenced it in transform activity. but the resulting html is not as required, all the elements of xml are coming in html side by side;
but when i used this same html code out side of tibco, it is working fine as it is showing in a well formatted table.....
Then my question is will tibco xslt execute html code or not ?
I am not too sure about using xslt transform activity for parsing a xml into html file.
Try parsing xml and then write file activity . You can alter the content of the file as per your requirement with tags and data from the parsed xml file.
I've created .ascx user control and I'm trying to find a way for including it into xslt rendering. How can I do this? I'm doing it for Sitecore. I thought maybe create a placeholder, but placeholders cannot be defined in renderings. I appreciate any help you can provide.
It's not possible to include ASCX file into xslt file because: XSLT transforms XML to HTML or to XML or to plain text but not to ASP.NET pages.
You can include xslt file into ascx but not ascx into xslt file. The best way is to change your xslt file into ascx file, and to include there with placeholders or directly .
I'd suggest to avoid using XSLT.
They seem pretty easy to use, but it's really hard to refactor the code.
Well, it's not possible to call user controls(.ascx) directly from XSLT files. However depending upon what you want to achieve, you can call .net methods, called XSLT extension methods, from XSLT file. For instance, you may need to write code similar to below to call custom .Net GetData() method.
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:customObject="urn:yourNamespace">
<new-data>
<xsl:value-of select="customObject:GetData()"/>
</new-data>
...
Of course the type needs to be registered before it can be used. Type registration can be done into web.config or dynamically by calling AddExtensionObjectMethod of XSLTArgumentList class.
Sitecore offers XSLT extension controls too and unlike extension methods, it isn't a .net feature. XSL extension controls are XML elements in XSL renderings that correspond to .NET classes. For example, the XSL extension control corresponds to the
Sitecore.Web.UI.XslControls.Text .NET class. It will be consumed something like this in XSLT file:
XSL extension controls are standalone elements in the XSL code.
To register a custom type, add following to element in web.config:
<extension mode="on" type="NamespaceName.ClassName, AssemblyName" namespace="http://www.w3.org/1999/XSL/Transform" singleInstance="true"/>
Reference: http://sdn.sitecore.net/upload/sitecore6/64/presentation_component_xsl_reference_sc62-64-a4.pdf
I have some XML and a very small XSLT to convert that into HTML. When I import my XML content in InDesign using the XSLT, I can see the styles are applied to the elements on the left hand browsing side but, when I drag and drop the elements in the InDesign frames, nothing is happening. The content is flowing normally.
My question is, in InDesign, is XSLT getting used only for sequencing the elements or can we use XSLT to apply the styles (like font-size, line-spacing etc.) as well for elements?
Also, if you can send me any sample XSLT for converting an XML to HTML tags or any example, that will be great.
In general, formatting in InDesign has nothing in common with CSS styles -- that is a HTML construction, not an XML one. You can indeed only reorder elements (and other element-wise stuff, such as removing, replacing, or adding tags).
Formatting can be applied to the tags after you imported/translated your XML using Map Styles To Tags (or Map Tags to Styles; I don't think I've ever used either).
You can use HTML within XLST so, if you have something like:
<xsl:value-of select="node"/>
Then this can also be written like:
<div class='style'><xsl:value-of select="node"/></div>
Or you can use inline CSS like:
<div style='color:red;'><xsl:value-of select="node"/></div>
Hope this helps!
I have a large number of HTML files that I need to process with XSLT, using an XML file to choose which HTML files, and what we're doing with them.
I tried:
Use HTML Tidy to convert HTML -> XHTML / XML
Use document(filename) in XSLT to read in particular XHTML/XML files
...use standard nodeset commands to access e.g. "html/body/*"
This doesn't work, because:
It seems that XSLT (tried: libXSLT/xsltproc ... and Saxon) cannot process XHTML documents as external files (it sees the xhtml DOCTYPE, and refuses to parse it as nodes).
Fine (I thought) ... XHTML is just XML, I just need to put it through HTML Tidy and say:
"output-xml yes ... output-html no ... output-xhtml no"
...but HTML Tidy ignores you if you attempt that, and forces html instead :(. It seems to be hardcoded to only output XML files if the input was XML to begin with.
Any ideas for how to:
Force HTML Tidy to obey the command-line parameters, and set the doctype I asked for
Force XSLTproc to parse xhtml DOCTYPEs as xml
...some other cunning way that will work?
NB: this has to work on OS X - it's part of a build process for iOS apps. That shouldn't be a big problem, but e.g. any windows-only tools aren't available. I'd like to achieve this with standard open-source cross-platform tools (like tidy, libxslt, etc)
I finally discovered why XSLTproc / Saxon were refusing to parse the files if they were passed-in with a DOCTYPE html:
The DOCTYPE of the external document alters how they interpret the
xmlns (namespace) directive. Tidy was declaring (correctly)
"xmlns=...the xhtml: namespace" - so all my node-names were ... I don't know: non-existent? ... inside my XSLT. XSLT was just ignoring them, as if they didn't exist - it needed me to provide a compatible mapping to the same namespace
...strangely, if the DOCTYPE was xml, then they happily ignored the xmlns command - or they allowed me to reference nodes by unqualified name. This fooled me into thinking that they were point-blank ignoring the nodesets inside the xhtml DOCTYPE'd version.
So, the "solution" is something like this:
modify your XSLT stylesheet to ALSO import the "xhtml" namespace - NB: this is required so that you can reference the nodes in the external files
write all your XSL match / select / template rules with the "xhtml" prefix on every node (and every attribute, I think?)
let Tidy output whatever it wants: it doesn't matter, it'll Just Work, once you have the namespace support in there
Example code:
Your stylesheet goes from this:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
...to this:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xhtml="http://www.w3.org/1999/xhtml">
Your select / match / document-import goes from this:
<xsl:copy-of select="document('html-files/file1.htm')/html/body"/>
...to this:
<xsl:copy-of select="document('html-files/file1.htm')/xhtml:html/xhtml:body"/>
NB: just to be clear: if you ignore namespaces, then it seems XSLT will work on files that are unDOCTYPED, even if they have a namespace in them. Don't make the mistake I made of thinking your XSLT is correct just because it appears to be :)
XHTML is XML (if it is valid).
To get your XHTML processed as XML, you must not serve it as "text/html" MIME. Use application/xhtml+xml instead (keep in mind, that IE6 does not support to render this and will prompt a download window for your site).
In PHP do you serve it as xhtml+xml with the header() function.
I think this should do the trick:
header('Content-Type: application/xhtml+xml');
Does this help?
If you run xsltproc --help, among the accepted input flags is a very conspicuous one called --html which supposedly tells xsltproc that:
--html: the input document is(are) an HTML file(s)
Presumably for this to work you must have valid HTML files to begin with, though. So you might want to tidy them up first.
I think the main problem is given by the XML catalog doctype declaration. You can test this by removing the external entity reference in the input XHTML and see if the processor correctly works with it.
I would do as follows:
Use Tidy with doctype omit option.
Add the Doctype at XSLT side as described here
The main problem is that Saxon and xsltproc has not any option to disable external entities resolution. This is supported by MSXSL.exe command line utility with option -xe.
It's been a while, but I remember trying to use HTMLTidy to prep HTML files for XSLT and was disappointed by how easily it gave up while trying to "well form" the HTML. Then I found TagSoup, and was very pleased.
TagSoup also includes a command-line processor that reads HTML files and can generate either clean HTML or well-formed XML that is a close approximation to XHTML.
I don't know if you're bound to HTMLTidy, but if not try this: http://home.ccil.org/~cowan/tagsoup/
As an example, here's a bad HTML file:
<body>
<p>Testing
</body>
And here's the tagsoup command and its ouput:
~ zyoung$ java -jar /usr/local/tagsoup-1.2.jar --html bad.html
src: bad.html
<html><body>
<p>Testing
</p></body></html>
Edit 01
Here is how tagsoup handles DOCTYPEs.
Here's a bad HTML file with a valid DOCTYPE:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<body>
<p>Testing
</body>
</html>
Here's how tagsoup handles it:
~ zyoung$ java -jar /usr/local/tagsoup-1.2.jar --html bad.html
src: bad.html
<html><body>
<p>Testing
</p></body></html>
It isn't until you explicitly pass a DOCTYPE to tagsoup that it attempts to output one:
~ zyoung$ java -jar /usr/local/tagsoup-1.2.jar --html --doctype-public=html bad.html
src: bad.html
<!DOCTYPE PUBLIC "html" "">
<html><body>
<p>Testing
</p></body></html>
I hope this helps,
Zachary
I would like to make certain lines of a DocBook table of contents bold based on whether the particular <section> has a certain attribute defined. This is easy by adding an <xsl:if test="..."> statement to the DocBook XSL (fo/autotoc.xsl lines 187-230 -- this is for output to PDF using XMLMind).
I'm wondering, though, if it's bad practice to edit the DocBook XSLs themselves. I have other customizations in a separate XSL of my own, mostly setting parameters, but I can't imagine how I would introduce this conditional logic--based on which line of the TOC is currently being processed--without putting some sort of code in the originals. Any thoughts? How do you upgrade to a newer DocBook XSL after making changes?
Import the docbook stylesheets from your own XSLT. Then, (re)define the Docbook template that you want to "override".
Since your template will be the highest in the import tree, it will take precedence.
By doing it that way you don't have to modify any of the core docbook XSLT files. It will make upgrades of the Docbook stylesheets easier in the future.
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:import href="xsl/fo/docbook.xsl"/>
<xsl:template match="template-that-you-need-to-redefine">
...
</xsl:template>
</xsl:stylesheet>