Re: XML: The good, the bad, and the ugly

On Mon, 4 Oct 2004 18:12:55 -0500, "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote:

>"Lemming" <thiswillbounce_at_bumblbee.demon.co.uk> wrote in message
>news:60e3m0l1q69rp04b5o5iasso8d5pnuc525_at_4ax.com...
>> On 4 Oct 2004 13:39:19 -0700, gnuoytr_at_rcn.com (robert) wrote:
>>
>> >as historical perspective, xml as B2B (and to a lesser extent B2C)
>> >implementation of data transport,
>>
>> Please forgive my ignorance: what is B2B (or even B2C?)?
>>
>> >arose from the assertion (not true from
>> >actual experience, i suspect) that using the xml plumbing (parser, https,
>> >vpn, etc) would be cheaper and easier than existing EDI implmentations
>> >which, IIRC, are binary data streams over VAN/WAN. it wasn't that xml
>> >was even a better bullet, let alone a magic one.
>>
>> ISTM it's not even a bullet. It's a software recruitment agency's wet
>> dream. It has nothing to do with writing robust systems, and
>> everything to do with having a shiny new buzzword with which to dazzle
>> prospective clients. Not exactly worthless, but nothing we haven't
>> seen before. In short: a lot of fuss about nothing.
>>
>> Hmm ... perhaps XML is about to become my equivalent of Dawn's 1NF.
>
>Then I'll give you one little tip. You need to know XML inside and out
>before you make these claims. Some of what you have said I'd agree with,
>but some of it seems more like hot air.
>
>While the format of XML is tagged data, with metadata tags instead of some
>other delimiters (such as commas) and therefore "nothing we haven't seen
>before", and as a bulky payload it seems like an unnecessary hit on
>performance, web services are another story. Web services that are built on
>top of the XML format provide a means for one company to provide software
>services that another company can use (including remote procedure calls)
>without either company sharing any information about the tools they use to
>do the work, other than the XML structures as the API.

I'm afraid I still don't get it. Is there something special about Web services that makes XML the best choice here? Is it not the case that the programs reading/updating the XML need to be able to make sense of the meaning of the XML? Or could someone write a generic program which will take any XML and make sense of it in a useful way (useful being something more than just presenting it in a report). Whyy would XML be a better solution than, say, a database back end (please try to answer without menioning 1NF).

It still seems to me that XML is just another file format, slightly more humanly readable than csv, but no more intelligible to a machine without specific programming to tell the machine what to do with the contents of the XML, and perhaps less so.

I accept that it is likely that I just don't know enough about it's other uses yet, but I do want to crack this nut if I can. After all, I'll be spending quite a lot of time working with XML at my current site and if I could see anything in it to merit wanting to work with it again I'd be more inclined to add XML to my CV.

>Whether we think it a silly, ignorant, or brilliant approach, it is
>definitely part of an approach that is going to lead to something decidedly
>new and useful. As such it is not just a "shiny new buzzword". If you
>don't like XML, then you might want to pick an alternative. Jini services
>using Java objects might be a better approach, for example, but there does
>need to be an approach.

But I must ask: why do we have to pick a "one-size-fits-all" approach? Why is that better than deciding what is best for a particular application?

If you have to transfer a million customer records across a bandwidth-limited network you most probably wouldn't choose to do it in a bloated format like XML - although unfortunately that is *exactly* the bloated format which has been selected by my client's and their parner's suits to transfer millions of customer details once a day down a 1Mb line. Even compressed, that's going to take a lot more time than a <hack, spit> csv or even a flat file, filler and all.

>XML isn't brain surgery, but it is likely to make a significant impact that
>really does advance the state of B2B software (although I would choose Jini
>services for any department-to-department services within a company and
>ditch the bulky XML).

One quick web-search later ... I found what appears to be the Jini home page (http://wwws.sun.com/software/jini/). I've not read very far, but it doesn't appear to me that Jini is trying to solve the same problems as XML. As noted above, the task I have in hand is to transfer daily around a million customer's data from one company to another. Jini doesn't look like a solution to this problem, but frankly nor does XML. It also looks to be heavily dependent on Java (at which point I stopped reading). Is this assumption correct?

>Just my $.02. Oh, and by the way, did I mention that XML has one thing
>going for it -- it is not trapped into that silly 1NF rule that has no basis
>in the mathematics of relations. Cheers! --dawn

I still don't understand this. XML, it seems to me, actually imposes 1NF, although admittedly in a more limited way than a RDBMS. There is obviously more to this than meets the eye. Perhaps (have I said this before? I've certainly thought it) the presence or absence of 1NF rules is in the eye of the beholder: I look at the structure and see 1NF being enforced due to the hierarchical nature of XML. You see the same data structures and see freedom from 1NF.

Lemming

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