Hi @JonasK and welcome to the KNIME community. Also thank you for the kind words. I’m pleased to hear that you have found this useful so far
Unfortunately I’m away from my PC all of this week which is going to make answering your questions difficult. Is this something you need urgently?
I was looking to improve on the XML generator components but work kind of got in the way, lol …
If you are able to wait a while I will endeavour to provide additional information and/or help with your specific problem. It will be good to have a real world scenario with which to improve the XML generator.
Actually it is not very urgent, but the target for me is to build such a xml like in attachment within in this year - so if you have time and fun I would be very thankfull!
Hi @JonasK , do you have some sample data that you will be using as the source for the XML you are trying to generate? I’ll take a look when I am back and have sone free time, but the solution will ultimately depend on the nature and format of the source data. And while I’ll be looking to help by enhancing my component, others may wish to assist you by using the standard KNIME functionality for creating xml.
please find attached this xml. It is an xml published by the financial office of austria: U30_UStVA_Struktur (5).xml (3.2 KB)
I found a workaround with the “Column to XML” node. It works, yes, but it is not as elegant and efficient as your solution because it is a lot of “manually node work” if you know what I mean. The XML Generator is much easier to handle by using the control table.
Hi @JonasK, do you have some the sample input data from which the xml would be generated, or maybe the sample/demo workflow you have already tried? It would be easier for me to work with something you already have than to try to make something up. thanks.
Hi @takbb ,
thanks for sharing this workflow, I just have a small comment. Would it be possible to replace the control tables with an xsd schema? I haven’t figured out how to add individual attributes for the xml element in the control table. the use of the already known xsd scheme would be easier for the user. Thank you for any new version of the generator with the xsd scheme.
Hi @Lukasbrezina . Welcome to the KNIME community, and thank you for your interest in the XML Generation component.
Certainly being able to use an XSD would be a nice thing, but the trouble with an XSD is that whilst it describes the format of the XML, it doesn’t describe how the data is sourced for each element, especially if the data table being used has different element names.
However, building a skeleton “control table” from an XSD is certainly something that I can see would be useful, and maybe in the future that is something I could look at doing. Unfortunately it won’t be any time soon but thank you for the suggestion. I will have a think about if there is any quick way of doing that.
I have however been looking at writing other components to assist with the control table generation and I hope to upload these at some point when I have found some spare time to look at them some more. In the meantime though, if you have a small XSD that you would like to post as a sample (you would probably need to rename it as .txt to upload it), I may be able to find time to give pointers about how to manually turn that into the control table that the generator needs.
Hi @takbb, Thank you for welcoming me to the Knime community.
In the attachment, I am sending an xsd scheme (generated from the resulting xml file), which I would like to convert to a control table vzor-21-2.txt (11.3 KB)
I will be very happy if you upload new components for generating the control table, maybe even with the help of an xsd scheme.
Would you be able to supply an example data table (just a few rows) that represents the data that you are trying to turn into the XML, as then I’d be better able to help.
Hi @Lukasbrezina , is that actual or dummy data? I’m assuming it is dummy data, but if actual data then best to remove that again if you can.
But ideally could you upload an actual data file with dummy data, as I was hoping to use it to help with ensuring the control table works. Otherwise I have a lot of typing to do! thanks
Hi @Lukasbrezina , thanks for uploading the sample data. I can see that mostly the data columns can be manually matched to the different items in the XSD, but are you able to give an example of what you think the resultant xml would look like given your data.
The XSD shows that there are a number of optional “attributes” (e.g. “label”, “type”, …), so would you be trying to match your data to any of these attributes, or would you be wanting them to remain blank, or excluded? It is questions like this which make “just” using an XSD great in theory, but not so great in practice because there is nothing to show where the data comes from…
Your interest has given me some inspiration to work on this, and have a look again at building further components to assist with xml generation, so hopefully we can go somewhere with this.
Hi @takbb ,
thanks for your time.
I am sending a new template vzor-21-2.xsd.txt (3.6 KB) for generating an xml file and an xml file with an example of assigning data from a db table Sk-21_schema.xml (2.1 KB)
We have removed the attributes, they are unnecessary for further work, and the data types are described in the template.
The sent xml file could serve as a source for generating the control table.
There were some small changes I needed to make to your uploaded files.
In the xml, I removed the repetition of the <PremisGas> structure, as this would cause problems, and corrected: <GasPremiseType>$GASPREMISETYPE$</GasPremiseType>
to <GasPremiseType>$GASPREMISETYPEID$</GasPremiseType>
to match the data that you posted previously
So it now looks like this: Sk-21_schema.xml (1.2 KB)
I am working on a “simple” process for working out the minimum from the xsd and xml that would allow me to create some form of control table compatible with the xml generator. I am not posting the workflow yet as I am still working on it, but I wanted to post a piece of generated XML based on the above. I ran it through a basic online xsd validator and it passed, but please take a look at it and let me know if this appears correct to you:
If that looks good, then soon (maybe later this week, if I get the time!) I will upload the components to public so that you can try them for yourself.
Hi @takbb
great job, replace the item <GasPremiseType>$GASPREMISETYPEID$</GasPremiseType> to <GasPremiseType>$GASPREMISETYPEDES$</GasPremiseType> and it will be perfect.
Would it be possible to adapt the resulting xml file to one line or without the xml structure, due to the size of the file? Would it be possible to add the current generation date to the file name?
Thanks for the quick generator edits.
Hi @Lukasbrezina, I think there was one omission in the xml sample I uploaded and that was that the first two <LicTable> elements should have been just one, as they have the same <LicId> ,and then their <TEZGroup> elements should have been grouped together. This is also the same for other groupings for LicTable in the input data.
I dusted off the work I’d done last year on building some components and incorporated features to use your XSD and XML. This is just the start… I feel there is still further work and improvements that can be done, but I now think the components are at a stage where they can be “released” to the hub for use (and testing!). I’m pleased with the result and hope they help you too. There may be bugs though so please use with caution!
Here is a link to a workflow on the hub using your sample data
The workflow consists of a few standard nodes, which are outnumbered by the components! The data, XSD and the mapping XML are fed in through standard readers. Then dedicated components translate the XSD and the mapping XML into “XML Control tables” which are merged together using the Override XML Generator Control Table.
The structure of the XML is defined by the resultant combined control table, but to ensure that the batching together of elements beneath <TEZCadasterGroup> and <TEZGroup> occurs, the Set Group Parent Identifier XML Tag component is used to specify the “id” element for the parent of each of these. So this is really the one piece of manual intervention in the whole thing!
Some zero-config housekeeping is performed by the XML Control Table Finalizer, and the XML is generated by the XML Generator. Data In:
The components are now all on the hub too. These can be found in the following location
Documentation
I have created a pdf as an overview document to the various components, as there are quite a few, although not all of them were required for doing your workflow. I need to add more to it, but that’s enough for one week!
In answer to your most recent question:
The resulting filename can be whatever you wish. The XML Generator places a file name into the RowID column of its output datatable, and this can be configured to be used in the standard XML Writer node, but if you wish to use a different (dynamic) file name, just add in a String Manipulator node or similar prior to the XML Writer, and have it create your required file names.
If the size of the output file is too large, then I would think you could wrap this into a loop (e.g. a Group Loop), in combination with some prior nodes to mark logical “batches” of records in the input data table with “batch numbers”. Each batch would then be supplied the XML Generator, and you could incorporate the batch number into your output file name, for example.
When you say “adapt the xml into one line, or without the structure” you mean get rid of all the additional “pretty printing” whitespace between elements? It doesn’t do that at the moment, but I can add that as an option.
Blockquote
When you say “adapt the xml into one line, or without the structure” you mean get rid of all the additional “pretty printing” whitespace between elements? It doesn’t do that at the moment, but I can add that as an option.
Yes exactly, remove all “pretty printing” and write everything in one line to reduce the size of the output file. An option in the XML generator would be the best solution.
Hi @takbb
I would need to change one parent tag, but change parent node changes all occurrences.
My problem is that Create XML generator Control Table from XSD put TEZCadasterGroup in PremiseElecOutputsGroup instead of PremiseElec as you can see from the picture.
Hi @Lukasbrezina , there is second component for changing parents called Change Specific Parent XML tag. Hopefully that should do what you need but let me know if not.
