We Keep Coding

count all occurences of xsl:result-document in a given stylesheet

I have an issue with part of my application in which I have some utility classes for xslt transformation functionality. I use SaxonHE as XSLT Transformer implementation.
My helper class has a function: URL mapFile(URL input, String stylesheetPath).
That takes the URL of one XML-File as input and returns a URL for the created XML-File. It handles the initialization and execution of the XSLT transformation.
But a stylesheet could theoretically create multiple XML files with xsl:result-document tags and I would like my utility class to be able to recognize if the given stylesheet will do that and handle it properly.
My idea was to analyse/parse the stylesheet from within my Java code and count all occurences of xsl:result-document.
With the values of the href-attributes, I would also know where the stylesheet creates the output XML files since I want to return a URL that points to their location.
So my changed utility method would be: List<URL> mapFile(URL input, String stylesheetPath) and return a number of URLs based on how many files are created by the given stylesheet.
But I have no idea how to do this in Java code and all my google searches concerning counting elements in a xsl stylesheet resulted in explanations how to count XML elements of the input XML from inside the stylesheet, which is not what I want to do.
EDIT: I ended up not doing any parsing of the stylesheet at all. I just create a folder and if someone writes a stylesheet that doesnt put all result files in that folder then it is their fault if they dont get a URL back for that result document . A hacky solution but it works for my use-case.

For a single-module stylesheet it's very simple: just execute the XPath expression count(//xsl:result-document).
For a stylesheet with multiple modules it gets more complicated because you have to follow xsl:include and xsl:import references, and more particularly, you have to detect cycles in the include/import graph so you don't go into an infinite loop.
You could export the stylesheet to a SEF file and execute count(//*:resultDoc) on the SEF file. Unfortunately that's Saxon-EE which will cost you money, but then writing the code by hand will cost you money too...
But actually you've asked for two different things. First you say you want to know the number of xsl:result-document instructions, then you say you want to know how many result documents are created. These aren't the same thing, because you don't know how often each xsl:result-document instruction is executed.
I suspect you can solve the problem by registering a result document handler with Saxon and using it to monitor calls on xsl:result-document at run-time.

Use xpath instead of XSD object generation for accessing XML details?

There is an XML file hosted on a server that I want to parse. Normally I generate an XSD from the XML and then generate the java pojo's from this XSD. Using jackson I then parse the XML to a java object representation. Is it not more straightforward to just use xpath ? This means I do not need to generate a object hierarchy based on the XML and also I do not need to regenerate the object hierarchy if the XML changes. xpath seems much more concise and intuitive ?
Why should I use XSD , object generation instead of xpath ?

According to the XML Schema specification XSD is used for defining the structure, content and semantics of XML documents. This means that you can use XSD to validate your XML file.
Depending on your circumstances you might be able to do without generating the whole object tree if all you need is to get some values from the XML file. In this case XPath is the way to go. However, you still might want to have an XSD file in order to validate the XML file before parsing it. This way you make your software fail fast, when the structure of your XML file changes, which will suggest that you change your XPath expressions. But for this to work, you shouldn't use the XSD you generate from your XML file, instead you should have a separate pre-generated XSD file which complies with the XPath expressions.

I think both approaches are valid, depending on the circumstances.
At the end of the day, you want to extract the values from that remote xml file and do something with them.
First criteria to consider is the size of that file, and the number of data elements.
If it's just a few, then xpath extraction should be straightforward. However, if that xml file represent a sizable and/or complex data structure, then you probably want the de-serialization to a Java data structure that you can then utilize, and JAXB would be a good candidate.
JAXB is going to be easier/better if the remote server adheres or publishes an XML Schema. If it doesn't, and changes often and significantly, you're going to suffer either way, but particularly so with JAXB. There are ways to smooth things over by pre-processing that xml with XSLT to force it into a more reliable form, but that is going to be a partial solution most likely.

modifying xml document using xml parsers?

I have an xml stored in database table. i need to get the xml and modify few elements and put the xml back in the database.
I am thinking to use JDOM or JAXB to modify the xml elements. Could you please suggest which one is better regarding the performance?
Thanks!

JAXB and JDOM and completely different things. JAXB will serialize java objects into an XML format and vice versa. JDOM simply reads in the XML file and stores it in a DOM tree which can then be used to modify the xml itself. So better if you go for JDOM.

JAXB is to be used when you have objects where the attribute values are stored in XML hence you can parse an xml document and it gives you a java objects and then you can write these back.
Quite a bit of work if you want to simple change some values. And it doesn't work with arbitrary xml files, JAXB has it's own format linked to your object's definitions.
JDOM creates also objects but the objects used are XML objects like Element, NodeList, ...
If you just want to change some values -> why not reading the xml file as a plain text file and use string operations to make your changes.
Or of the modification is more logicaly defined -> use an XSLT and a stylesheet translator.
Googling for XSLT and Java will give you tons of examples.

how to create a new word from template with docx4j

I have the following scenario, and need some advice:
The user will input a word document as a template, and provide some parameters in runtime so i can query my database and get data to fill the document.
So, there are two basic things i need to do:
Replace every key in the document with it´s respective result from the current query line.
"Merge" (copy? duplicate?) the existing document unchanged into itself (append) depending on how many rows i got from the query, and replacing the keys from this new copy with the next row values.
What´s is the best aprroach to do this? I´ve managed to do the replace part for now, by using the unmarshallfromtemplate providing it a hashmap.
But this way is a little bit tricky, because i need to add "${variable_name}" in the document, and sometimes word separates "${" and "}" in different tags, causing issues.
I´ve read about the custom xml binding, but didn´t understand it completely. I need to generate a custom XML, inject it in the document (all of this un runtime) and call the applybindings?? If this is true, how would i bind the fields in the document to the xml ? By name?

docx4j includes VariablePrepare, which can tidy up your input docx so that your keys are not split across separate runs.
But, you would still be better off switching to content control data binding, particularly if you have repeated data (think for example of line items in an invoice). Disclosure: I champion this approach in docx4j.
To adopt the content control data binding approach:
dream up an XML format which makes sense for your data, and write some code to convert the results of your database query into that format.
modify your template, so that the content controls are bound to elements in your XML document. ordinarily you'd use an authoring add-in for Word to help with this. (The technology Microsoft uses for binding is XPath, so how you bind depends on your XML structure, but, yes, you'd typically bind to the element name or ID).
now you have your XML file and a suitable intput docx, ContentControlsMergeXML contains the code you need to create an instance document at run time. There's also a version of this for a servlet environment at https://github.com/plutext/OpenDoPE-WAR
As an alternative to 1 & 2, there is also org.docx4j.model.datastorage.migration.FromVariableReplacement in current nightlies, which can convert your existing "${" document. Only to a standardised target XML format though.
If you have further questions, there is a forum devoted to this topic at http://www.docx4java.org/forums/data-binding-java-f16/

Best practice to parse xml file with same content but based on different schemas

I need to parse xml files from two sources. Both xml files contain the same content but each source uses their own schemas. This means the values that i want to extract from the xml file will be stored in different element names depending on the source of the file.
Here is an example - Assume i am only interested in the "name" of a product.
Source 1
-------------------------
<item>
<itemname>Camera</itemname>
<itemprice>20</itemprice>
</item>
Source 2
-------------------------
<productList>
<productName>Camera</productname>
<ProductPrice>20</productprice>
</productList>
To parse the above i have to know the source of the xml file and then either do a
getElementsByTagName("itemname");
or
getElementsByTagName("productName");
My original plan was to have a different parser for each source's xml file but i am thinking that maybe i could write a generic parser if i specify the path to the element i need. The benefit of this is that i can then process any xml file from any source without having to modify the parser.
What i am thinking of doing is to store the path to the element on to a properties file. i.e.
source1.name="itemname"
source2.name=productName
The generic parser would then just retrieve the element based on the name i provide it. This will probably work but i am thinking that if i am interested in more than one element it might be cumbersome to maintain it via a properties file.
Is there a better way to resolve the above? Please note that One restriction that i am limited to is that the target platform for this is JDK 1.4 so xpath etc would not work.

The ideal solution is XPath. No matter how different the XML inputs are, you can store an XPath for each as a string in a properties file. There are several XPath-compliant parsers that work with JDK 1.4.

If element names follow a convention (*Name, *Price), you could write a generic parsing function using wildcards and XPath. Or you could write it based on tag orders if they are always the same (you can do this without XPath).