Skip to main content

I need to export data of an oracle database to XML, it’s data from an electricity network, so not highly structured or nested.
I created a workbench using the xml-templater and got some results, so far so good.
Are there any limitations using the XMLtemplater compared to the XSD-driven Writer?
I don’t want to create the whole export and realize later, that I would have better chosen the XSD-driven Writer for XML.

Also a little problem with XML templater:
I created an Attribute Value using Attribute Manager, a simple number “0.4”.

When I write this value using the XMLtemplater it gets written as “0.40000000000002” to the Textfile.
What am I doing wrong?

 

 

Hello @reservoirdog, if there is a schema available for use the format/spec you’re writing too, I recommend using the XSD-Driven XML Reader/Writer. This will write XML documents conforming to an existing & valid XML Schema document, opposed to you templating/formatting it yourself in an XMLTemplater (XSD’s usually also make things like interpretation, validation, and value control easier). 

Regarding the corrupted value, can you try using the @round(<number>,<precision>) function in the XMLTemplator > Template > Text Editor > Math Functions? Curious to see if this will restrict the 0’s.

Otherwise, are you able to test the latest official version and let me know if the behvaviour persists? You can find the latest available version here: https://fme.safe.com/downloads/.

On an aside - we have an upcoming webinar that will review some of these things: https://fme.safe.com/webinars/optimizing-xml-json-workflows-for-seamless-data-integration/ Happy to help, Kailin. 


I’ve recently had this exact same problem. Using

<namespace:xmlTag>
{fn:format-number(xs:double(fme:get-attribute("numberAttribute")), "0.00")}
</namespace:xmlTag>

was wat worked for me. For some reason the @round() function did not do it for me. There is an explanation somewhere that I had thought I’d bookmarked, but I can’t find the bookmark anymore (nor the article). It does make sense of why this is happening, btw.


 Hi @kailinatsafe and thanks for your inputs.
Will give it a try using the XSD-driven XML Writer, though until now I got a bit confused on how to use it, opposed to the quite simple XMLtemplater.

I tried using the math-function round without success.

The way @s.jager described worked for me, thanks so much!


Hello @reservoirdog & @s.jager, I did a bit more digging yesterday and found an existing issue that relates to this: FMEENGINE-73347. FMEENGINE-73347 was filed for the XMLTemplater changing the precision of real64 values to floating points. 

The workaround is similar to what @s.jager already shared, which is awesome!
<value>{fn:round(xs:double(fme:get-attribute("example")), 2)}</value>

Unfortunately, this behaviour has not been addressed in the latest official build yet, but I will take some time to add it into the Known Issues 2021.x article for the time being.

I think the key to working with XSD Writer is to ensure the feature paths are selected in the XSD Writer parameters so the writer knows how to map the fme attributes to the appropriate elements. Here is an article that demonstrates the steps! Happy to help, Kailin


Found the article I mentioned in my previous post: Floating Point Precision and String Formatting in FME. That article recommends using the AttributeRounder or the @round-function, neither of which worked combined with the XMLTemplater in my case. So that article might benefit from an update mentioning the fn:format-number function in specific cases.

 

I’m adding all of this here as well, just in case somebody else runs into this challenge. Oh, and btw:  found the solution I used here.


Hello @s.jager, great find - I will make a note to update the article. Many thanks, Kailin


Reply