|
On Wed, 6 Mar 2013, at 10:16:43, j.beckeringh@xxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
Either I don't understand you or we disagree :-)
Don't you always have to check the data after the parsing? And is 'if
numCustomerID = 0' better than 'if CustomerID = *BLANK'?
Yes - but you're missing the point. What if it was not a missing entry but (say) a letter? Or a numeric formed in a fashion that RPG will not convert? E.g. 12,345.00 or 123CR. Or simply "N/A" or ...
I tend to see the XML-document as a box full of data items; through
XML-INTO I pick out the items that I'm interested in and leave the others
alone (allowextra=yes). Before the parsing I initialize the DS, after the
parsing I check whether I have enough data to do whatever I need to do.
I'd rather do this checking afterwards than having the XML-INTO bomb out
on me.
Fine except that this means that you are always dealing with a document that will fit into memory. If you have to use %Handler this approach will not work as you cannot initialize the memory.
It also means that if the supplier changes names of elements, changes an element from simple to compound, etc. and "forgets" to tell you, you may have no warning. If this doesn't ever happen to you, fine.
So indeed I am using 'allowmissing=yes' and 'allowextra=yes' as defaults
and I'm quite happy with it, thank you very much.
Please note I was not attacking you personally - if this approach works for you fine. But there are many examples out there where extra/missing are alwauys specified/recommended because they were often needed to avoid the problems that early versions of XML-INTO had. I was merely trying to point out for the archives that in most cases these were no longer necessary.
I would still say that using "missing" as a default is a bad idea.
Jon Paris
www.partner400.com
www.SystemiDeveloper.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.