I downloaded Netbeans 8.0.1 to create some XSLT files. Here is a small example:
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<html>
<body>
<h2>My CD Collection</h2>
<table border="1">
<tr bgcolor="#9acd32">
<th style="text-align:left">Title</th>
<th style="text-align:left">Artist</th>
</tr>
<xsl:for-each select="catalog/cd">
<tr>
<td><xsl:value-of select="title"/></td>
<td><xsl:value-of select="artist"/></td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
The autocomplete feature of Netbeans works complete without problems, if you have a simple XSLT file or a simple HTML file. But if you mix up those two files, the autocomplete feature just works for XSLT.
Beginning with the <html> tag, i don't have autocomplete anymore, even not for the XSLT tags at the end of the file.
Does anyone know if this is a bug or just some settings to use autocomplete for HTML and XSLT?
Holy GNU, after a whole afternoon on that, I managed to get both XSL and HTML auto-complete working on the same XSL file.
Download an XSD version of HTML5
HTML is not XML, so we must take a look on XHTML5 (HTML serialized as XML). I've taken the XSD from there
Tell netbeans to use it
The xhtml namespace http://www.w3.org/1999/xhtml must use the XSD we've downloaded. So, in Tools → DTD & XML Schema → User catalog, add a local Schema where the System ID is http://www.w3.org/1999/xhtml and the URI is the xhtml5.xsd you've downloaded.
You may need to restart netbeans (I actually restated it so many times I cannot tell whether it's required or not).
Use the xhtml namespace in the XSL
Now, in the XSL, tell that you're using the xhtml namespace with the attribute xmlns="http://www.w3.org/1999/xhtml" on the root node.
<xsl:stylesheet version="1.0"
xmlns="http://www.w3.org/1999/xhtml"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>
You could also have added this xmlns attribute to each most-top-level html node (aka, each html node that has no html node in their ancestors). You can also use xmlns:html on the root node, and use <html:*> instead of <*> nodes. It's useful if you have multiple namespaces like HTML+SVG+MathML+XSL.
Enjoy html auto-complete
You should then have the auto completion for html. It requires that you explicitly type the first html tag, but once inside an html tag, the auto complete works (so, if you're making a table inside a xsl:template, you'll still have to type the <table> but once inside, auto complete will suggest things like <caption>, <thead> and so on).
What about auto-complete XSL inside the HTML?
It requires an edit in the xhtml's XSD. We must declare the XSL namespace in the XSD using xmlns:xsl="http://www.w3.org/1999/XSL/Transform" on XSD's root node. Then, we must tell in the XSD that every HTML node can contain an XSL node. This is done by using <xs:any namespace="http://www.w3.org/1999/XSL/Transform" processContents="skip"/> in all elements groups <xs:group>.
Once these edits are done, the XSD says "Every HTML node can contain an element from XSL's namespace", so Netbeans's auto-complete will suggest XSL nodes too.
You can download the edited XSD I'm using here: http://xenos.reinom.com/stackoverflow/xhtml5.xsd
In case you're wondering, I made a long detailed response so you can do the same if you want to mix XSL and SVG or XSL and any other XML-XSDed format.
Related
my problem is as follows:
I'm downloading an xml file using express.js and then parsing that file. Right now it looks something like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE item [ ]>
<item lang="EN" >
<country>US</country>
<doc-number>123123123</doc-number>
<kind>A1</kind>
<date>20191017</date>
</item>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE item [ ]>
<item lang="EN" >
<country>US</country>
<doc-number>0938409384</doc-number>
<kind>A2</kind>
<date>20191018</date>
</item>
I'm using the xml2js library and I'm having trouble getting the entire document. My code looks something like this
parseString(xml, function (err, result) {
console.log(obj);
})
The XML only outputs only the first piece of xml. How can I parse this so I can get an array of <item>s?
My first idea is to loop through the doc as a string and split it based on <?xml version="1.0" encoding="UTF-8"?> and parse the data that way.
Thanks!
I do not think you can have more than one xml declarations for a single xml document. Additionally, a root element must always be present.
Therefore, the xml document you have provided is 2 separate xml documents, in principle. Most parsers or APIs would probably reject it, as not well formed.
Do you have any control over how the document is generated? If yes, you should ensure that a single xml declaration and a single root element will be present. Something similar to:
<?xml version=“1.0” encoding=“utf-8”>
<items>
<item>…</item>
<item>…</item>
</items>
If you do not have any control on the generation, you should probably split it and parse the documents separately, or concatenate them and generate a document similar to the one above.
Instead of modifying the stock templates that come with many suites, I'd like to extend the stock templates so when the stock template gets upgraded/updated with a new version, I can keep my own XSLT extension/modification of the stock XSLT and use to process with as well. Similar in function to a source code patch file or CSS inheritance.
For example, if the stock XSLT doesn't have enough spaces in the separation between footnotes when processing to HTML, I'd like to add my own XSLT for that footnote that adds a space.
In DocBook XSL stylesheets terms want you want to create is called a “customization layer”.
The basic idea is, put your customizations in a customizations.xsl or whatever file and then use your XSLT engine of choice to call that instead of the stock DocBook XSL driver file; like this:
xsltproc customizations.xsl my-docbook-source.xml
As far what exactly you put into the customizations.xsl file, if all you want to change is some of the user-configurable DocBook XSL params, it’s as easy as:
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:import href="html/docbook.xsl"/>
<xsl:param name="html.stylesheet" select="'corpstyle.css'"/>
<xsl:param name="admon.graphics" select="1"/>
</xsl:stylesheet>
And if you need to replace a whole template:
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:fo="http://www.w3.org/1999/XSL/Format"
version="1.0">
<xsl:import href="fo/docbook.xsl"/>
<xsl:template match="lineannotation">
<fo:inline font-style="italic">
<xsl:call-template name="inline.charseq"/>
</fo:inline>
</xsl:template>
</xsl:stylesheet>
So because instead of you directly calling the DocBook XSL driver file from the command line, you call your customization.xsl file and it needs to call the right DocBook XSL driver, then for the href values in, e.g., the <xsl:import href="html/docbook.xsl"/> elements, you just need to put the path to wherever the stock DocBook XSL stylesheets+driver are on your system.
For example, on a Debian system:
<xsl:import href="/usr/share/xml/docbook/stylesheet/docbook-xsl/html/docbook.xsl"/>
Caveats
If you need to make any changes to one of the templates in the stock stylesheets, you copy-paste the entire template into your customization layer and make your changes to the template there.
XSLT doesn’t give any more change-making granularity than that—e.g., you can’t have your layer contain just a two-line patch for part of a template. You have to copy in the whole template.
A consequence of that is, if the upstream maintainers change/fix some other part of original template you made a copy of, your customization layer is not going to pick up that change unless you re-copy the new upstream template in again and make your tweaks to it again.
But that’s probably not going to cause you any problems in practice because these days I think the upstream DocBook XSL templates don’t change very often.
Also note that some of the templates in the DocBook XSL stylesheets are huge—so your layer can end up being a relatively big file even if you only need to make a single-line patch
Yes it is possible for XSLT. Go for <xsl:apply-imports/>.
A template rule that is being used to override another template rule (see 6.4 Conflict Resolution for Template Rules) can use the xsl:apply-imports or xsl:next-match instruction to invoke the overridden template rule.
W3 apply-imports
I have a problem that seems to be related the svg names spaces. One way works with FireFox and the other way works with Chrome but neither way works with both. I have tried adding xmlns="http://www.w3.org/2000/svg", but that doesn't change the results either way.
In the template below, the 'use' and 'text' tags are prefixed with 'svg':. This works in FireFox but not with Chrome. If I remove the 'svg:' prefix then it works in Chrome but not FireFox.
Is there a way that works with both?
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns="http://www.w3.org/1999/xhtml" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:svg="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<xsl:output method="html" encoding="UTF-8" indent="no"/>
<xsl:template name="attribute-header">
<svg:use xlink:href="#attribute-value-section-banner" x="{$location-x}" y="{$banner-y}"/>
<svg:text class="attribute-label-text" x="{$center-line}" y="{$label-y}">
I wrote two test cases, one being http://home.arcor.de/martin.honnen/xslt/test2015020801.xml that uses the stylesheet http://home.arcor.de/martin.honnen/xslt/test2015020801.xsl with xsl:output method="xml", the second being http://home.arcor.de/martin.honnen/xslt/test2015020802.xml which uses the stylesheet http://home.arcor.de/martin.honnen/xslt/test2015020802.xsl with <xsl:output method="html". As long as the output method is xml, the XSLT can produce prefixed SVG elements (e.g. svg:circle) and all three browsers I have, IE 11, Firefox, and Chrome render the XHTML and the SVG just fine. In the second test case with output method html I have made sure that the SVG elements are not prefixed as neither HTML5 nor HTML 4 supports that syntax. Again all three browsers know how to render the HTML and SVG created that way by XSLT.
So I suppose you are mixing HTML output with XML namespaces and prefixed qualified names, decide whether you want to create XML with your XSLT, as in my first example, where you then have full support for XML and XML with namespaces syntax, or whether you want to create HTML5 with your XSLT, where you then have to stick to HTML5 syntax which does not support prefixed element names and only a few predefined attributes (see http://www.w3.org/TR/html5/syntax.html#attributes-0). That way you should get consistent results.
I am currently studying ways to present transformed xml files in browsers. My experience with this is minimal, so a number of questions pop up.
I have a transformation test.xslt which transforms input xml to html, and an input file test.xml containing
<?xml version="1.0" standalone="yes"?>
<?xml-stylesheet type="text/xsl" href="test.xslt" ?>
<root>...</root>
which, when opened in IE9, neatly displays the transformed xml contained above in the root element.
Question 1
Is there a processing instruction or similar available to include the source xml into the xml to be opened, somewhat like the following:
<?xml version="1.0" standalone="yes"?>
<?xml-stylesheet type="text/xsl" href="test.xslt" ?>
<... instruction to include source file data.xml>
Question 2
The file opened has extension xml. Is there a way to change file contents so it is valid html, allowing the file to be saved with extension html, so that when opened, the default browser will be selected (simply changing extension to html obviously does not have the desired effect so some structural change is necessary) ?
Question 3
My goal is to query a db to get the data to be parsed by the xslt code. What is the best way to do this (no problem if this includes javascript)?
Question 4
Standard db utilities may export query results in attribute-centered fashion (column names and values being represented as attribute names and values). This may involve pre-parsing the xml from db in order to convert it to parent-child fashion (columns as children instead of attributes). What is the best way to do this pre-parsing (note: I already have the xslt for this; I wonder about the data flow and when/how to run two xslt's in sequence) and then apply test.xslt (preferably without saving intermediate xml result files on the server)?
Question 5
When I open above xml in IE9, this works fine as said. But opening it in Firefox errors (RTF issue, apparently I need to use Firefox's node-set function but I still have to discover which namespace that has), and Opera/Chrome/Safari do not show any content. What exactly are the prerequisites for the various browsers where can I find more information on this?
Q1 If you start by serving an html file which then accesses the xml and xslt via javascript it naturally has access to both the input and the output of the xslt. If you are serving the xml and initiating the transformation using xml-stylesheet pi, then perhaps the best thing to do (depending on what you want to do) is to stuff the original source into the output, then javascript in the generated page can access it if needed, eg
<xsl:template matcj="whatever">
<html>
<head>
<script id="source" type="x-xml-spurce">
<xsl:copy-of select="/"/>
</script>
.... whatever you were going to do
then if you need to access the source in response to a user action on the page, a script can retrieve the script with id source and do whatever is needed. (If there is a possibility of the the source including the string you have to code it a bit more defensively).
Q2 If you want to use the xml-stylesheet API then you have to serve it as xml. However you can instead just serve html and then access the xml and xslt from within a script in the html page using the browsers javascip xslt api. as noted above that is more flexible than the xml-stylesheet mechanism.
Q3 pass
Q4 If you are accessing the xslt from javascript then it is easy to chain the output of one to the input of another without writing back to the server as you just have access to the result as a DOM node (or string, depending)
Answer to question 5: Firefox/Mozilla, Opera, Safari, Chrome all support the EXSLT node-set extension function in the namespace http://exslt.org/common, for IE and MSXML you can use script (imported) inside the XSLT stylesheet to allow it to support that namespace too, see http://dpcarlisle.blogspot.de/2007/05/exslt-node-set-function.html. That way inside the main stylesheet where you need to use the node-set function you don't need to write different code to cater for the different namespaces.
I am building a menu and have it set up so that I use a standard <!--#include virtual = "myDoc.xml" --> SSI tag to include my xml document. The xml document includes the xsl document with <?xml-stylesheet type="text/xsl" href="myOtherDoc.xsl"?>. For some reason the xsl document is not working. The xml is being displayed as a blob.
Unfortunately your XSL transform won't work like that. You'd have to send the XML document alone to the browser where the built in xsl transformer would then reference the stylesheet and perform the transform.
What you've got is an HTML page already being rendered and you're including the XML as just a chunk of xml rendered into the output stream, but the browser won't know to transform it because it doesn't have the:
<?xml-stylesheet type="text/xsl" href="myOtherDoc.xsl"?>
...PI at the start of the page. Remember these are processed by the browser not the server.
You would need to transform the XML server side e.g.
<!-- #include virtual="doMenuXform.asp" -->