Re: Xquery might have some things right

From: Corey Brown <corey_at_spectrumsoftware.net>
Date: Fri, 5 Mar 2004 10:41:30 -0500
Message-ID: <9812c.52808$Tn.22205@bignews5.bellsouth.net>

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:zr02c.32190$XD3.7410_at_newssvr16.news.prodigy.com...
> "Corey Brown" <corey_at_spectrumsoftware.net> wrote in message
> news:Se02c.16672$JN2.13942_at_bignews4.bellsouth.net...
> >
> > "Eric Kaun" <ekaun_at_yahoo.com> wrote in message
> news:dn%1c.55833$1O4.38437_at_newssvr33.news.prodigy.com...
> > > "Corey Brown" <corey_at_spectrumsoftware.net> wrote in message
> > > news:gZ_1c.46418$0l1.21653_at_bignews3.bellsouth.net...
> > Sure, that's why you need an AAIS (application to application
> interface specification),
> > otherwise how will you define the contract between one system and the
> other?

> Definitely - my point was that XML doesn't absolve you of that
> responsibility.

>


> >     XML does have "some" advantanges. Here's a short list:

> >

> >     - It's human readable. Developers can visually check on communications

> between systems

> >        simply by taping into the communications channel. Great for

> debugging too.

> Recently I've been dealing with comma-delimited data being sent from one
> system to another. I find it no less readable than some of the XML docs I
> cope with at work. In some simple, short cases, you might be right, but for
> a system of any sophistication, I find the format tedious. I still need a
> tool (like XMLSpy) to cope with the inevitable removal of line breaks from
> XML streams - I can't read those things in one big block. And if I have to
> open a tool, well, many tools will work. XML is fine for writing short docs
> in a text editor - after that, things get hairy.

Ok, but there's no reason why the "XML" has to be hairy. comma-delimited data has it's advantages and disadvantages too. Inparticular, how do you send a variable length list of data for any particular variable in a CSV document? There are advantages and disadvantages to both approaches. :-) I just find XML to be rather convenient sometimes.

>


> >     - Senders and receivers don't have to be in perfect sync. That is,

> information can be added

> >        at the transmitter that the receiver can simply ignore. This works

> especially well in a publish

> >        subscribe scenario where the subscribers use the published output

> in different ways.

> That's true of my comma-delimited data too. I have a line with field names.
> It's trivial to suck the data and field names into Perl and get a nice hash
> of field to value, and trivial to only grab the ones you care about. All
> with less code than typical XML-related code (even with a parser!).

Ah, but you've kinda stretched the meaning of CSV in that you have included both a name AND a value pair separated by comma delimiters. You also still have the same problem as mentioned above. You can't define variable length lists of values for any particular name or attribute. When I think of CSV, I think of pure values separated by commas. In which case the client and server must be in perfect sync.

> I'm not advocating comma-delimited, by the way - just mentioning that I've
> yet to see many of the stated benefits of XML materialize for me.

I think both have their place in solved certain classes of computing problems. It's always good to have more tools in your tool box than not. ;-)

Regards,
--Corey

> - erk

>
> Received on Fri Mar 05 2004 - 09:41:30 CST