Re: Why do you use XML?

On Feb 8, 2:50 pm, "Scott Roberts" <srobe...@xxxxxxxxxxxxxxxxxxxxxx
software.com> wrote:
Indeed you are right. The standard method for handling embedding
spaces (or even commas in CSVs) is to use quotes or some other
character. Again, Regex handles this very well.

Except that in my experience, there are subtly different rules for
different flavours of CSV. Then you've got the issue of escaping
newlines etc.

Indeed. Sometimes you wrap all strings in quotes, sometimes you only wrap
strings in quotes if they contain a comma. Our CSV output routines have a
bajillion configuration options to accommodate all of the different systems
we output to in this "standard" CSV format.

Unless you are working with an extremely deleveloper-
unfriendly format, I say it is just as easy to pull data out no matter
what. The only benefit to XML is that someone already did most of the
parsing work for you

That's a pretty huge benefit.

However, writing a custom
parser can be as simple as a regex expression, so why force your input
into XML when SSV or CSV is readily available?

I'm currently writing import routines for our application. We get mostly
fixed-width files. Parsing these files in code is not technically
challenging, but when there are 300+ fields it can be tedious. Then, of
course, there are the times when something has gone wrong and I have to
inspect the raw data. This requires that I have the file format on hand so
that I can find the offset to the field I need. Oh, and does the format give
the offset from 0 or 1? Well, that depends on the format.

As I keep saying, it depends on *exactly* which flavour of CSV you're
using. Or perhaps it's actually fixed record. Or some horrible mixture
of the two. Maybe there's a header line or maybe there isn't. You have
to change the code to cope.

Or add many, many config settings.

I'm not arguing with you. I am just pointing out that it is a matter
of the environment, and so far what you are said doesn't intice me to
rely on XML. I still don't see how XML can benefit me *here*.

The title of your thread is "Why do you use XML?". I don't think that anyone
is trying to convince you to use XML. Quite the opposite, almost everyone
has said that if the shoe doesn't fit don't wear it.

In my environment, we work primarily with CSV and SSV. Relationships
are typically formed on the database or are fixed. Again, XML repeats
the data definition every time. I would call this the biggest waste
generator when using XML. It's just not that practical in my
environment.

We get some pretty big fixed-width files (tens of millions of records).
There's no doubt that if they were XML they would be much larger. But even
so, bandwidth and disk space are cheap. I wouldn't mind at all if they were
XML.

What does it extract, where does it go? How does it
magically make your code know what to do? At some point you the
developer must know what the data *means*. You need to know where to
find the data. You need to know where to put it. That requires knowing
the syntax *and* the symantics. Unless you have found a way to
overcome this need for developer intervention? Did ya? 'Cause that
would be something I would like to have in my possession!

There are no doubt people in this world that say "Just use XML!" as if that
solves all of the world's problems and ends the discussion. However, I've
not seen such a reply in this thread. I initially had the same reaction you
are having - XML is just a pretty face on an old technology (flat files).
And in some respects it is. But it really does offer some useful features
under certain circumstances.

But if you think about it, all of these applications of XML are due to
someone deciding to jump on the XML train. They didn't have to use
XML. What about the "in-between". Anyone can send a format over a
network. Does XML provide a benefit that couldn't have been achieved
otherwise?

Ask yourself this: flat-files have been around since the dawn of computers,
so why aren't there a plethora of tools focused on reading/writing CSV and
fixed-length files? Oh, there are tools out there, to be sure. But why don't
they dominate the market like XML tools? They had a 50 year head-start and
are still being ousted by XML in many areas.

or do these applications use XML because it makes their
code seem more up-to-date? or do they use XML because of the pre-built
tools available?

IMO, human readability and pre-built tools.

I would venture that someone could create a CSV
standard document format and the tools to work with it that could
rival any XML-based platform.

EDI tried to do that very thing. I guess it was moderately successful among
larger companies, but after taking one look at it I ran away crying.

Only for two dimensional data though - less flexible. You'd then also
need something equivalent to xsd/dtd for extra validation - to
describe that a particular column could only contain numbers, for
example.

By the time you'd added all of that kind of thing - and the ability to
embed one document within another, etc, I think you'd find all the
attractive simplicity of CSV had disappeared.

And how! I have 6 volumes of EDI specs for submitting simple orders. No
thanks!

Create the tools and you will have
people who use your format. Especially if you can convince them that
it is "the way" to do data tranfer.

Again, CSV was "the way" to do data transfer for decades. The fact that it
is being replaced in some circumstances is really all the proof you need
that it was inadequate. Either the format itself was never standardized or
the few tools that were actually created to help read/write them were not
sufficient - or both. Regadless, the proof is in the pudding.

I honestly agree with everything you and Jon Skeet are saying. I am
just taking the devil's advocate (probably out of bitterness). What
confuses me is that 4 years ago my company adjusted this meter reading
device to accept XML. Now, this year, they have suddenly decided to
move to a CSV format. The problem with grunts like me is that we don't
see the reasons why we are writing code. All we see is the request and
are told to get it resolved ASAP. People like myself know about tools
like XML and want to incorporate them into our designs. However, some
times what seems the "right" wasn't an option because some big-wig
makes a quick decision without involving the grunts. I think a lot of
companies forget or are completely unaware that involving the measley
computer scientist is part of the CSs job! I am here to give me
professional opinion! I feel a lot of companies reduce developers to
code monkeys, and that's not right.

In any case, I feel like my confidence in XML is restored. When the
entire development community defends a tool, it must be useful. No
argument there. I suppose I will spend the next few years succeeding
and failing to use XML correctly until I get it right. But like I said
in a post long ago, this was the first time in 2 years where using XML
seemed like a via solution. Maybe I shouldn't expect to create my own
XML, but use the XML that is written for me. I mean, I already work
with serialization, SOAP and configuration files. Additionally I might
call the folks asking for the CVS and ask them why they changed their
minds suddenly. I suppose letting the grunt be a little more involved
could solve some of these issues up-front.

Thanks to everyone.
.

Relevant Pages

  • Re: Why do you use XML?
    ... different flavours of CSV. ... It is just the same as not knowing which XML format you are using. ... An XML parser doesn't try to understand the data, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why do you use XML?
    ... different flavours of CSV. ... XML has a standard. ... I believe you're confusing synactic format with semantic format. ... An XML parser doesn't try to understand the data, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: xml data vs. ODBC text driver
    ... Excel can import XML data, but to have it "natively" open, you will need to ... format the XML in Excel format. ... There are quite a few ways I can think of to get to CSV format, ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: What is the logic of storing XML in a Database?
    ... can't do with CSV. ... In what a header does constitute a schema. ... So a schema is the standard structure by which the user sending a file ... in much the same way that XML standards are. ...
    (comp.databases.theory)
  • Re: ultra newbie question (dont laugh)
    ... storing employee information in an XML file. ... but not as fun as writing the logic. ... On reason to use OOP is to insulate your main code from things like storage ... from CSV file. ...
    (comp.lang.python)