Re: Why do you use XML?

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.

.

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)