You would need/want more fields like "iteration" for repeating data
segments. In the end it would operate similar to a DOM parser in that you
could then create a wrapper service program around the table that allows
statements like the following:
unqId = XMLParse('/somefile.xml');
custNum = getElemData(unqId: '/AccountDetailList/Account/Number': 1);
So you accomplished the retrieval of the XML data in two lines of code.
The unqId field is so you can relate the parsed data to a set of records
in the DB2 table that is used on all subsequent calls - almost like an IFS
handle. The third parm is stating which iteration of the "Number" you are
looking for.
There is a lot more that would need to be programmed to account for all
scenarios (I know because one of Krengel's developers just got done
writing this for our next version of RPG-XML Suite - www.rpg-xml.com :-) -
but this would work for simple XML docs.
Aaron Bartell
http://mowyourlawn.com
Adam Glauser wrote:
Aaron Bartell wrote:
Once XML data is in a more OS400/RPG/DB2 native format it
is much easier to work with IMO and would make it so no other programmer
in your shop would ever have to learn to parse XML.
This is an interesting idea, and I want to make sure I understand what
you're suggesting Aaron. Would you end up with a table with two fields,
XPath and value?
I can see where this style of processing could come in handy, though I'm
not entirely convinced that it is that much harder to write %handler()
function than it is to process the same data using XPath retrieval. I
also think that a similar level of understanding of the XML structure
(via understanding the XPath) is necessary. Does your experience
suggest otherwise?
midrange.com
