I'm currently in the process of building an xml document through DS, and I've utilized one of the techniques in the Best Practices document.
Specifically, I'm using the technique in section 3.1.3.1.2 Addresses. In that technique, a series of addresses in a flat file are fed through a transformer to build xml tags, then through an xml output stage to produce an address list chunk, and finally through a hash file where it is read by the main stream in the job to be output with the other data in the desired xml format.
This technique is basically working for me (my "address" chunks are actually a series of instant messages), in that I get the chunk of data landing in the correct location in the file. The only problem I have is that once these chunks leave the xml output stage into the hash file, the formatting is out of whack. For example, instead of of the < and > tags, I get < and >.
I could probably convert these in a subsequent job, but I'm guessing there must be some way (which I've yet to discover) of handling this in a more efficient way. Any suggestions are appreciated.
Tom
XML Best Practices doc question
Moderators: chulett, rschirm, roy
I guess it depends on your definition of "out of whack".
For actual XML data, that is exactly what those characters should be converted to to make them "safe". Stopping it is simple - there is a column called Data Type (I believe, can no longer check) that is normally blank but one of the values it can be set to is XML. This tells the parser that it is already "xml" and so to not convert anything in it. Should fix you right up.
For actual XML data, that is exactly what those characters should be converted to to make them "safe". Stopping it is simple - there is a column called Data Type (I believe, can no longer check) that is normally blank but one of the values it can be set to is XML. This tells the parser that it is already "xml" and so to not convert anything in it. Should fix you right up.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
"Data Element" is the property. On the input link of the XMLStage. As Craig notes, the "&" are proper escape characters for when string content containing xml (or anytime characters such as < and > appear) is placed "inside" xml tags as "values".......
When you set the Data Element to "XML" you are overriding this normal and correct conversion behavior, thus sort of "appending" more xml to your current document as opposed to "creating new value content".
Ernie
When you set the Data Element to "XML" you are overriding this normal and correct conversion behavior, thus sort of "appending" more xml to your current document as opposed to "creating new value content".
Ernie
Ernie Ostic
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
Thank you guys both for your replies.
I obviously don't have a lot of experience with xml, and after I posted I did some further reading and found that what I was seeing was normal.
A big thanks for telling me how to convert it. (I always wondered about the 'XML' value in the Data Element column - now I see its use!)
Thanks again.
Tom
I obviously don't have a lot of experience with xml, and after I posted I did some further reading and found that what I was seeing was normal.
A big thanks for telling me how to convert it. (I always wondered about the 'XML' value in the Data Element column - now I see its use!)
Thanks again.
Tom