Re: The politics of finding errors Was:XML

On Fri, 8 Oct 2004 08:21:20 -0400, "Laconic2" <laconic2_at_comcast.net> wrote:

>
>"Lemming" <thiswillbounce_at_bumblbee.demon.co.uk> wrote in message
>news:a2jcm015pihgtvd6ivne489or1ges4vsf2_at_4ax.com...
>> On Thu, 07 Oct 2004 21:57:16 GMT, Bernard Peek <bap_at_shrdlu.com> wrote:
>>
>> >In message <cjsldr$vui$1_at_news.netins.net>, Dawn M. Wolthuis
>> ><dwolt_at_tincat-group.comREMOVE> writes
>> >
>> >
>> >>XML isn't brain surgery, but it is likely to make a significant impact
>that
>> >>really does advance the state of B2B software
>> >
>> >I've used XML in a situation where it did provide real benefits. When
>> >the received data failed to validate it got bounced by the machine and
>> >never even reached a human. At a stroke that ended most of the arguments
>> >about whose job it was to fix malformed data files.
>>
>> There shouldn't really be an argument about it. If the data file is
>> invalid (whatever format it's in) it's the responsibility of the
>> creator of the file to fix it. A receiving system can't reasonably be
>> expected to guess what the data should have said.
>>
>> Having said that, I guess it's easier to spot certain types of
>> malformed XML, simply because the structure of the data is made
>> explicit in the file in the form of tags. OTOH the malformation is in
>> XML itself; If the XML validates, that says nothing about the quality
>> of the data within it. The point is you still have to write exactly
>> the same validation routines that you would have had to write if the
>> file was delivered in a flat file, csv or even in a deck of cards, but
>> with the additional overhead that when using XML you also have to
>> validate the delivery medium.
>>
>> Lemming
>> --
>> Curiosity *may* have killed Schrodinger's cat.
>
>There is something in the above exchange that deserves a discussion of its
>own.
>
>The fact that XML ended some arguments about whatever. Lemming's response
>was logical.
>
>The thing is: in an IT shop, a logical argument seldom carries the day.
>You would think that, since we all practice logic in our craft all the
>time, a concisely stated solid argument would end the discussion. If
>you've ever been through ongoing battles about whose fault it really is,
>you KNOW that it's not true. I don't have to prove it to you.
>
>Back when I was consulting, I was called in when the people were having
>problems with their database. At most shops, there was plenty of local
>talent, mostly full time employees. Most of these people were earning their
>pay, and were definitely worth keeping on board. But they had problems
>that they could not fix. And, with one or two exceptions, the problems
>were real.
>
>The idea that managers simply hire consultants to CYA when things are going
>south, and that the problems are just as bad when the consultant leaves as
>they were when the consultant arrives, just doesn't match my own
>experience. And it doesn't match what Joe Celko has said in here about
>fixing up people's databases either. Maybe that's the current industry
>trend, and maybe that's why I'm not as successful as I once was. If so,
>I'd rather drive a truck.
>
>As far my work was concerned, the EASY part was figuring out what was wrong
>inside the database. The HARD part was effecting change within the shop's
>culture. If you just fix the database and leave, you've added very little
>value, although you may have guaranteed some repeat business. If you just
>point out all the mistakes that were made, in a way that makes everybody
>embarrassed and angry, you won't even get the repeat business, and your fix
>will not be implemented.
>
>To really change things, you have to change the people. And that's HARD
>WORK. Even if it looks easy to those of you who watch a consultant breeze
>in, make a huge fee, and leave after just making a few key recommendations.
>If XML helps stop arguments about where the fault lies, that alone is a
>selling point for XML.

Apologies for the lateness of this reply ...

XML does indeed settle an argument. It settles the argument of whether the XML is valid. It says absolutely nothing about the quality of the data, about whether the receiving system should have interpreted/autocorrected this value or that value even though it was incorrect. It says nothing about data quality. Why should it? It's a file transfer format, not a verification tool. Sure there are tools which will validate the structure of the XML, but they don't verify the quality or accuracy of the data either - how could they? They have no knowledge of what the data means.

Checking the validity of data - as opposed to the structure of the data - is the job of the system which receives it. Would you expect the cardboard box that your new TV arrives in to be able to check that the TV is in working order? Of course not, that's your job - you plug it in and check that it works. You'd expect the box to have four sides, a bottom and a top, to be sealed and to have protective packaging inside it to keep the TV safe in transit, but after that the job of the box ends.

In the same way, XML is just the box that contains the data. It is expected to have a certain structure, and if it doesn't have that structure we can reject it. But that's all.

The only faults it will expose are faults in the XML format itself. It will not expose any errors inherent in the data which are not equally well exposed in any other file format, be it CSV, card image, or whatever. In fact, "well formed XML" may well even hide errors or give the sender yet another get-out.

You : "The data in this XML file is incorrect."

They: "Your system is at fault: the XML validates fine here."

How do you think the conversation goes on from here?

Lemming

-- 
Curiosity *may* have killed Schrodinger's cat.