Re: XML-SAX *XML_EXCEPTION event and reported parsed length question

I did take a shot at copying an XML to an 819-ccsid file - the characters that did not convert were replaced with x'1A' - I didn't see an option on the CPY command to change that - so that would need to have been changed en masse, since THAT byte also caused a parsing error.

I also thought, why not go for the gusto? Why not copy the original XML to a file in CCSID37? It would make it impossible to look at the XML in any standard editor, but maybe that wouldn't matter.

It replaced these non-convertible characters to x;3F; - I don't remember if I tried this morning to process that - I decided I would continue as I am with XMLTABLE - I would not easily convince anyone I should change directions, with again, the risk factor of unknown results.

On 7/13/2017 7:59 PM, Nathan Andelin wrote:

I was under the impression it wouldn't work. Maybe that
impression was mistaken?

It's a suggestion for Vern to try.

What happens to characters that are not
representable in the target CCSID?

I'm not sure. I think it would replace the EMOJI with something acceptable
to the parser. It would be worth a try.

I suspect that XML parsers load entire documents into memory, and build a
tree structure that references each element, attribute, etc. That would be
required for validation.

Then, if the document is valid, some sort of API can be used to extract
all, or a filtered selection of content. Different parsers expose different
APIs, and different capabilities.

I admit that extracting XML content into an SQL cursor might be precisely
what one needs. In other cases, the developer may need to look at each
element, attribute, etc. separately.