What the Daily WTF?

Savior

This post goes out for everyone like me, who believe that, yes, XML has its uses, only as a temporary storage format, used to exchange information between systems that do not talk directly.
But, as you all know, this is a overused, and overhyped technology that will be used to create standalone databases, to, believe it, programming languages.

Now, if you go to:

http://xplusplus.sourceforge.net

You will see that some jerk decided to create a programming language based on XML! What the fuck? Creating a language basend on a storage standard?
But it's not everything, you can check the wonderful examples, for example (Sorry if the code is messed):

The following code:

xpp {<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p>

       class XObj {<o:p></o:p>

              construct{ }<o:p></o:p>

              public:<o:p></o:p>

                     int    Arr[3] = {5,6,7};<o:p></o:p>

                     void   constructor() {<o:p></o:p>

                           string Names[3] = {Jack,Jimmie,John};<o:p></o:p>

                           int    x;<o:p></o:p>

                           for (x = 0; x <= 2; x = x + 1) {<o:p></o:p>

                                  xout("\r\nIn constructor this.Arr[" + x + "] = " + this.Arr[x]);<o:p></o:p>

                                   xout("\r\nIn constructor Names[" + x + "] = " + Names[x]);<o:p></o:p>

                           };<o:p></o:p>

                     };<o:p></o:p>

       };<o:p></o:p>

       ;<o:p></o:p>

       <o:p></o:p>

       int    a[3] = {10,20,30};<o:p></o:p>

       int    x;<o:p></o:p>

       for (x = 0; x <= 2; x = x + 1) {<o:p></o:p>

              xout("\r\na[" + x + "] = " + a[x]);<o:p></o:p>

       };<o:p></o:p>

       <o:p></o:p>

       node(XObj)    MyObj;<o:p></o:p>

       <o:p></o:p>

       for (x = 0; x <= 2; x = x + 1) {<o:p></o:p>

              xout("\r\nMyObj.Arr[" + x + "] = " + MyObj.Arr[x]);<o:p></o:p>

       };<o:p></o:p>

Will output the following:

a[0] = 10<o:p></o:p>

a[1] = 20<o:p></o:p>

a[2] = 30<o:p></o:p>

In constructor this.Arr[0] = 5<o:p></o:p>

In constructor Names[0] = Jack<o:p></o:p>

In constructor this.Arr[1] = 6<o:p></o:p>

In constructor Names[1] = Jimmie<o:p></o:p>

In constructor this.Arr[2] = 7<o:p></o:p>

In constructor Names[2] = John<o:p></o:p>

MyObj.Arr[0] = 5<o:p></o:p>

MyObj.Arr[1] = 6<o:p></o:p>

MyObj.Arr[2] = 7<o:p></o:p>

<o:p> </o:p>

<o:p>But will be saved in the xpp file like this:</o:p>

<o:p>

<xpp><o:p></o:p>

<class name="XObj" inherit=""><o:p></o:p>

<construct/><o:p></o:p>

<scope type="public"><o:p></o:p>

<arr type="int" name="Arr[3]">{5,6,7}</arr><o:p></o:p>

<func type="void" name="constructor"><o:p></o:p>

<body><o:p></o:p>

<arr type="string" name="Names[3]">Jack,Jimmie,John</arr><o:p></o:p>

<var type="int" name="x"/><o:p></o:p>

<for><o:p></o:p>

<init><o:p></o:p>

<eval object="x"><o:p></o:p>

<eval><o:p></o:p>

<expr>0</expr><o:p></o:p>

</eval><o:p></o:p>

</init><o:p></o:p>

<cond><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<expr>Parm0 <= 2</expr><o:p></o:p>

</eval><o:p></o:p>

</cond><o:p></o:p>

<step><o:p></o:p>

<eval object="x"><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<expr>Parm0 + 1</expr><o:p></o:p>

</eval><o:p></o:p>

</step><o:p></o:p>

<xout processcode="true"><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<parm type="int" name="Parm1"><o:p></o:p>

<eval object="this" member="Arr"><o:p></o:p>

<index><o:p></o:p>

<eval object="x"/><o:p></o:p>

</index><o:p></o:p>

</eval><o:p></o:p>

</parm><o:p></o:p>

<expr>"\r\nIn constructor this.Arr[" + Parm0 + "] = " + Parm1</expr><o:p></o:p>

</eval><o:p></o:p>

</xout><o:p></o:p>

<xout processcode="true"><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<parm type="string" name="Parm1"><o:p></o:p>

<eval object="Names"><o:p></o:p>

<index><o:p></o:p>

<eval object="x"/><o:p></o:p>

</index><o:p></o:p>

</eval><o:p></o:p>

</parm><o:p></o:p>

<expr>"\r\nIn constructor Names[" + Parm0 + "] = " + Parm1</expr><o:p></o:p>

</eval><o:p></o:p>

</xout><o:p></o:p>

</for><o:p></o:p>

</body><o:p></o:p>

</func><o:p></o:p>

</scope><o:p></o:p>

</class><o:p></o:p>

<arr type="int" name="a[3]">10,20,30</arr><o:p></o:p>

<var type="int" name="x"/><o:p></o:p>

<for><o:p></o:p>

<init><o:p></o:p>

<eval object="x"><o:p></o:p>

<eval><o:p></o:p>

<expr>0</expr><o:p></o:p>

</eval><o:p></o:p>

</init><o:p></o:p>

<cond><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<expr>Parm0 <= 2</expr><o:p></o:p>

</eval><o:p></o:p>

</cond><o:p></o:p>

<step><o:p></o:p>

<eval object="x"><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<expr>Parm0 + 1</expr><o:p></o:p>

</eval><o:p></o:p>

</step><o:p></o:p>

<xout processcode="true"><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<parm type="int" name="Parm1"><o:p></o:p>

<eval object="a"><o:p></o:p>

<index><o:p></o:p>

<eval object="x"/><o:p></o:p>

</index><o:p></o:p>

</eval><o:p></o:p>

</parm><o:p></o:p>

<expr>"\r\na[" + Parm0 + "] = " + Parm1</expr><o:p></o:p>

</eval><o:p></o:p>

</xout><o:p></o:p>

</for><o:p></o:p>

<node name="MyObj" class="XObj" processcode="true" construct="true"/><o:p></o:p>

<for><o:p></o:p>

<init><o:p></o:p>

<eval object="x"><o:p></o:p>

<eval><o:p></o:p>

<expr>0</expr><o:p></o:p>

</eval><o:p></o:p>

</init><o:p></o:p>

<cond><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<expr>Parm0 <= 2</expr><o:p></o:p>

</eval><o:p></o:p>

</cond><o:p></o:p>

<step><o:p></o:p>

<eval object="x"><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<expr>Parm0 + 1</expr><o:p></o:p>

</eval><o:p></o:p>

</step><o:p></o:p>

<xout processcode="true"><o:p></o:p>

<eval><o:p></o:p>

<parm type="int" name="Parm0"><o:p></o:p>

<eval object="x"/><o:p></o:p>

</parm><o:p></o:p>

<parm type="int" name="Parm1"><o:p></o:p>

<eval object="MyObj" member="Arr"><o:p></o:p>

<index><o:p></o:p>

<eval object="x"/><o:p></o:p>

</index><o:p></o:p>

</eval><o:p></o:p>

</parm><o:p></o:p>

<expr>"\r\nMyObj.Arr[" + Parm0 + "] = " + Parm1</expr><o:p></o:p>

</eval><o:p></o:p>

</xout><o:p></o:p>

</for><o:p></o:p>

</xpp><o:p></o:p>

<o:p> </o:p>

<o:p>Congratulations, dickhead, now, I need a special tool just to read the fucking source!</o:p>

<o:p>What the Fuck where you thinking when you had this stupid idea??</o:p>

</o:p>

Savior

Hey, at least, XML is human-readable!
Now, we can brag not only for using XML as a database, but also that we are using X++ - A programming language made of XML!

Talk about Buzzword and hyping now.

SeekerDarksteel

Maybe we're lucky and he did it as a joke.

*prays*

apapadimoulis

I hate XML. Not only is it abused (like this) but it sucks at what it was designed to do. A "human readable" format intended to be read by machines. Seriously, WTF?

I'm not sure, however, what's worse -- the XML Database (it exists), the XML Programming Language (it now, aparantly, exists), or the XMLImage Format (it exists as SVG).

don

@Alex Papadimoulis said:

I hate XML. Not only is it abused (like this) but it sucks at what it was designed to do...

Occasionally I read or hear someone say something like this, but
usually it's not in an open forum where I can ask questions - today's
my lucky day!

Question for the XML haytaz: What's so bad about it for its originally
intended use? As a way of serializing structured data as characters it
may not be the very best conceivable, but it's not too bad. Why the
hate?

BTW, this is not the first (or even the second) attempt at creating an
XML app that is a programming language. I forget the number, but if you
go back a few years in Dr. Dobb's you'll find a previous attempt...but XSL was shown to be Turing complete shortly after it's proposal in 1999.

tofu

@Alex Papadimoulis said:

A "human readable" format intended to be read by machines. Seriously, WTF?

Obviously you've never written a program to read-in a binary file when
you didn't have the file's definition or any kind of custom libraries
to do it.

I still have nightmares of the year (yes a whole year) when I had to
convert data that had been created by a custom-made application that
someone had written to do hand receipts for an army unit.
Apparently some soldier with some programming experience had created it
years ago. It was actually a very nice program but nobody had the
source code. I had to figure out the binary output files by
pouring over them with a hex editor. The record length varied and
there were some really weird tricks used to avoid duplicating
strings. It was a really unpleasant experience. I never did
fully decode the files. I was able to get the important stuff
though and they had someone manually reenter the rest.

I think that if you knew what binary files looked like you wouldn't
badmouth XML. Do you even know what high-low format is? I
bet you don't. You're lucky to live in the era of human readable
formats.

Trust me, XML is a good thing.

masklinn

@don said:

@Alex Papadimoulis said:
I hate XML. Not only is it abused (like this) but it sucks at what it was designed to do...

Occasionally I read or hear someone say something like this, but
usually it's not in an open forum where I can ask questions - today's
my lucky day!

Question for the XML haytaz: What's so bad about it for its originally
intended use? As a way of serializing structured data as characters it
may not be the very best conceivable, but it's not too bad. Why the
hate?

I think that the Does XML Suck slides may help you.

XML is overly verbose (like SGML, but much worse) for both humans and machines which is both frustrating for a human reader/writer and very bad for stockage and transmission purposes
XML is overly complex, to write (artificial separation between elements data and attributes, yet no guidelines about what should be an attribute and what should be element data) and to parse, and that leads to wondering what it's good for, is it for humans or for machines? (it's probably for none of them)
Multiple layers have been added on top of the base raw XML to both parse (DOM/SAX) and try to validate that stuff (DTDs(which suck), W3C Schemas, Relax, RelaxNG (Relax New Generation... god), TREX, Schematron), which all are subtly incompatible with each other as far as what they allow you to do (only DTDs let you use entity references for example)
Namespaces were added on top, because validity checking was still far too easy... probably...

XML is just used too often, it's base goal was supposedly the ability to be machine-independant for communications and exchanges, which was more or less fine (i guess, even though previous stuff could do it just as well), but it's been abused far beyond that, today the answer you get is "Let's use XML" before you even asked a question...

Mikademus

LOL! This is rich! I usually promote pragmaticism when reflecting over what to do, use and even like. And the author of the language seems quite disconnected from any practical considerations. He says this about it:

The name Superx++ was chosen because it emphasizes the potential of this
language. For instance, the courier messaging model is being extended to allow
for the creation of autonomous intelligent agents. It is intended that these
will bring into reality the vision of the semantic web. Superx++ is on a
good footing for this because the language itself as well as its objects are
XML and therefore can easily implement the encoded information in DAML and RDF
documents.

Now, I'm usually one who says all languages have their usefulness, and languages should be chosen by the problem to be solved, but for this one, I don't know...

tofu

@masklinn said:

XML is just used too often, it's base goal was
supposedly the ability to be machine-independant for communications and
exchanges, which was more or less fine (i guess, even though previous
stuff could do it just as well), but it's been abused far beyond that,
today the answer you get is "Let's use XML" before you even asked a
question...

ok. I guess I would agree with that. But I stand by my
statement that as a data storage and exchange format, XML rules.

It is overly verbose, but what is the alternative? As I said
before, if you ever had to decode a binary format, you would appreciate
XML more.

No, it shouldn't be used to make a programming language. I think
that was probably a joke. In fact, the person who did it is
probably just making the same point that you made: "har har, people
think XML is a good idea for everything, here is an XML language"
So, let's have a good laugh about that but let's not generalize to
suggest that when if comes to its actual intended purpose, XML isn't
the greatest thing since sliced bread.

Look, consider this, have you ever had to access somebody's weather
information service? Neither have I. Do you think that
would be hard to do? Well, in the days before XML, a company like
accuweather would probably happily give you data like this
141423423.4234 and (hopefully) give you a multi-page API for reading
it. If they didn't give you an API, good luck.

With XML, accuweather probably gives you data like, (temperature)50(/temperature)

I used parenthesis there because I'm not sure how to do greater than/less than on this board.

At any rate, every single XML parser ever written will undoubtedly be
able to read whatever it is that accuweather sends you. So if
someone asks you to get some data from a weather service and display it
somewhere, you can do it in an afternoon and be home in time to watch
24. The old way, you'd spend a lot of time trying to figure out
the data format.

versatilia

My 2p... I write SOAP services in mod_perl ('cos I'm a sadist) and I've really appreciated XML, but this X++ is just comical.

For laugh++, have a look here: http://www.topxml.com/code/default.asp?p=3&id=v20020930173054

They've realised that you can't code in XML so made a pre-parser which
converts a C-like version of the language into the full XML!!

(WTF++)++

Taliesin

First: XML Programming language -> that's nosense

Second: Blaming XML (as data interchange) -> what's wrong with you. I think that there are quite few programmers dumb enough to not realize that XML is something good for them. There are lot's of things that are good for our clients but there are quite few good for us, as others said the importance of XML is not for make your own data files, but to read others data.

I had succesfully implemented a multi price list decoder that actually reads data from 19 different providers (45.000 products) and is extensible, allowing the user to add new price-lists, this software would cost my customer a lot more if the data come in other formats like csv, excel or binnary. XML allowed me to cut my programming time, which allowed a lower cost, which finally grant me the contract.

There is another place where XML is perfect: if we want to store user preferences or configurations in scenarios where we traditionally use binnary files. The use of XML in those situations allow the user to manually change those things (we are talking about a software where this is desirable)

masklinn

@Taliesin said:

There is another place where XML is perfect: if we want to store user preferences or configurations in scenarios where we traditionally use binnary files. The use of XML in those situations allow the user to manually change those things (we are talking about a software where this is desirable)

No, that's a place where XML sucks balls.

One, because flat files is just as readable and actually easier to modify for the user

Two, because when you're using a lightweight interpreted high level language, it's much saner AND faster to just use the language itself to store your settings.

Storing settings and confs as binary is stupid, but storing them as XML is not much better.

Casiotone

I think one of the best things about this is that most of it is just plaintext expressions wrapped in XML, which reminds me of a recent daily WTF... (http://www.thedailywtf.com/forums/53714/ShowPost.aspx)

maldrich

That's all well and good, but -- as it's name implies -- can it increment by 11? All other questions are moot, really.

Savior

@versatilia said:

My 2p... I write SOAP services in mod_perl ('cos I'm a sadist) and I've really appreciated XML, but this X++ is just comical.

For laugh++, have a look here: http://www.topxml.com/code/default.asp?p=3&id=v20020930173054

They've realised that you can't code in XML so made a pre-parser which converts a C-like version of the language into the full XML!!

(WTF++)++

Dude, I think you have the WTF award of the Year there...
Sure it was done in 2002 but it sucks so much that it transcends the time!

(WTF++)++

rbriem

Great name.

X++ == Y (Why?)

apapadimoulis

@don said:

Question for the XML haytaz: What's so bad about it for its originally intended use? As a way of serializing structured data as characters it may not be the very best conceivable, but it's not too bad. Why the hate?

Hopefully you will find the linked website providing some of this information. But it's also important to consider the historical context here: XML is based on HTML. That dinky little markup language that (as far as markup languages go, sucks) is the parent of XML. That alone should elicit a WTF reaction. But I'll try to address my gripes from a data perspective.

First and foremost, consider that it is impossible to have any document be self-describing to a machine. While the average person will understand that "<message><from>Alex</from><to>Bob</to>...</message>" is obviously some sort of correspondence, it’s as useful to a machine as “<1234-vz3~~4-snmbkn3o!” For a machine to semantically understand a document, the format of that document must be strictly defined; this is just common sense.

XML has no built-in method for doing this. One must use a DTD, XSD, or some other technology to create a definition of the data so that a machine may validate it before attempting to read it. Each of these technologies has their own weakness in so much as it’s possible to do one thing in DTD that is impossible to do in XSD, and visa versa.

Despite having designed a document format, developed the specification, and agreed upon it between to two parties, one still is required to include metadata inside his data. Although the DTD specifies that a Widget will immediately be followed by a Sprocket, which will contain one or more Whizbangs, your document still needs to look like “<widget>some data</widget><sprocket><whizbang>data</whizbang></sprocket>”. Does that make any sense?

Wow, that took longer to explain that one point than I thought. Well, here’s a quick list of problems that I've have with it that I didn't see in the linked article ...

A single data type (string).
No way to do binary data (a sub-complaint of the preceeding)
Forces data to be heirarchical
Unpredictable record lengths, making seeking impossible (must read the entire document in to find the 100th record)
Elements vs Attributes -- just a HTML carryover
Even with DTD/XSD, sub-typing impossible

For a solid data interchange format (that, thankfully, none of the "big boys" have given up for the XML fad), see ASN.1.

masklinn

@Alex Papadimoulis said:

@don said:
Question for the XML haytaz: What's so bad about it for its originally intended use? As a way of serializing structured data as characters it may not be the very best conceivable, but it's not too bad. Why the hate?

Hopefully you will find the linked website providing some of this information. But it's also important to consider the historical context here: XML is based on HTML. That dinky little markup language that (as far as markup languages go, sucks) is the parent of XML. That alone should elicit a WTF reaction. But I'll try to address my gripes from a data perspective.

Bad alex, bad bad bad, no cookie for you!

I already told you that the ancestor (and more or less superset, in fact) of XML was SGML, HTML is merely an SGML language (and as far as markup languages go, I'd like to know why HTML sucks)

@Alex Papadimoulis said:

Forces data to be heirarchical

Unless you're using attributes, it should be noted, in which case you are forbidden to have hierarchical or ordered data (in a word, forbidden to have structured data).

@Alex Papadimoulis said:

Elements vs Attributes -- just a HTML carryover

Please. SGML.

Rodyland

OK, I'm only half serious here, but...

Think about a programming language implemented in XML. Ugly, verbose, hard to read, you name it, you're all right.

But then imagine a parser that converts that XML code into your
favourite language in your favourite formatting style. You write
code in C++. But it's saved as XML. Someone else is a Java
programmer, so when he opens your source he sees Java. Got a
module in FORTRAN that needs to be maintained, but nobody who knows
FORTRAN? No sweat, we've got C gurus galore....

Now, of course, this couldn't actually happen with today's programming
languages and today's technology, and the X++ language (from what I see
above) is not abstracted enough to allow such things either. But
it's a step in that direction.

But I also bet that someone out there with too much time on their hands
would be able to write something quick and dirty that parses the X++
XML and turn it into valid ANSI C++ or Java, and maybe go in the other
direction, too.

To me it's just another layer of abstraction, and I have little doubt
that one day what I've described above will be possible.
Useful? Hard to say, really, it's kind of like trying to do a
cross between the 'write once, run anywhere' thing that Java promised
but failed to deliver, and 'write anything, run on windows' that .NET
promises (not a .NET guru so forgive me), to give us a 'write
anything, run anywhere' that will probably end up being mandatory on
your resume. :)

masklinn

@Rodyland said:

OK, I'm only half serious here, but...

Think about a programming language implemented in XML. Ugly, verbose, hard to read, you name it, you're all right.

But then imagine a parser that converts that XML code into your
favourite language in your favourite formatting style. You write
code in C++. But it's saved as XML. Someone else is a Java
programmer, so when he opens your source he sees Java. Got a
module in FORTRAN that needs to be maintained, but nobody who knows
FORTRAN? No sweat, we've got C gurus galore....

If such a thing was even remotely possible you'd have languages translators, and you wouldn't need an XML bloat as middleware agent in the translation...

XML is not magic you know, just because you translate a program to some XML stupidity doesn't mean you can convert that stupidity back into another language...

James_Brantly

@Alex Papadimoulis said:

But it's also important to consider the historical context here: XML is based on HTML. That dinky little markup language that (as far as markup languages go, sucks) is the parent of XML. That alone should elicit a WTF reaction. But I'll try to address my gripes from a data perspective.

Actually, both HTML and XML came from SGML. Don't "blame" XML on HTML. HTML may have its problems but most of those problems are not syntax issues but specification/implementation issues which XML doesnt deserve to inherit by association.

@Alex Papadimoulis said:

XML has no built-in method for doing this. One must use a DTD, XSD, or some other technology to create a definition of the data so that a machine may validate it before attempting to read it. Each of these technologies has their own weakness in so much as it’s possible to do one thing in DTD that is impossible to do in XSD, and visa versa.

True, but I've found it to be neat that XSD is XML based. This points out something rather important about XML.. it's syntax, not structure (read: what-goes-after-what and what-datatype-is-this). Your argument here seems rather weak. XML was designed specifically for the purpose of being extremely flexible on structure. That's what it's "all about". And the fact that its flexible enough to be used to build a structure, such as XSD, that has the purpose of defining further XML structure seems to be a pretty neat accomplishment. I'm not sure how this is a flaw of XML, seeing as how you would need some way to define structure with ANY sort of formalized syntax used to store data. If I were to create some CSV file, sure, I know that each column is separated by a comma, and certain strings should be quote-enclosed, and quotes should be escaped, etc etc, but I still need some way to define what column goes where and what data is accepted where. At least XSD is somewhat industry standard and is machine-verifiable with pre-existing tools, as opposed to a Word file that might be emailed around to describe a CSV structure.

@Alex Papadimoulis said:

Despite having designed a document format, developed the specification, and agreed upon it between to two parties, one still is required to include metadata inside his data. Although the DTD specifies that a Widget will immediately be followed by a Sprocket, which will contain one or more Whizbangs, your document still needs to look like “some datadata”. Does that make any sense?

From a storage-efficiency point of view, no. From a "can a lame-person look at this and maybe figure out whats wrong quickly or how to gather data from it quickly" point of view, it makes perfect sense. It can also come in handy when coding things by hand. I know its not often that one might manually create data in a storage format, but then again, during the development and testing phases, not having to remember that the "Name" field is exactly 82 characters from the last line feed can be a blessing.

@Alex Papadimoulis said:

A single data type (string).

That can be used to store any number of other datatypes. That's almost the same as saying "A single data type (bit)."
@Alex Papadimoulis said:

No way to do binary data (a sub-complaint of the preceeding)

There are all sorts of encodings you can use to store binary data.

@Alex Papadimoulis said:

Forces data to be heirarchical

XML still allows for "flat" data. I see nothing wrong with a format having the ability to do both. I might need to have a root node, but thats about the only hierarchy that's "forced".

@Alex Papadimoulis said:

Unpredictable record lengths, making seeking impossible (must read the entire document in to find the 100th record)

Which is a problem with ANY storage format that has variable length data unless it includes a lookup table. This seems to be a tradeoff to me. A lookup table will improve performance, but adds extra data and adds the complexity of keeping the table updated. I'm unfamiliar with any other methodologies of achieving this, except for maybe "jump scanning" (each record has *gasp* metadata about its size, allowing you to jump over that record.) Anyways, for the proper uses of XML, which is NOT as a production database, I dont see this performance hit as a huge loss.

@Alex Papadimoulis said:

Elements vs Attributes -- just a HTML carryover

As I already mentioned, this is actually a carryover from SGML, not HTML. Otherwise, this point is conceded. There is no clear distinction between when to use attributes and when to use elements except that attributes cannot contain nodes.

Despite my defense here, I think that there is a LOT of bastardization of XML. I know too many people that think its the end-all of everything. Personally, I love XML, but I always try to take a step back when using it and think, "Should I REALLY be using XML here?", and many times I definitely come to the conclusion that I should not. However, for certain things, I think XML excels. Namely, for human-readable serialization, for some data-exchange (certainly not all, where efficiency is important), and for configuration files. *shudders whilst recalling the INI days*

This being my first post here, hopefully everything will format correctly. I apologize if it does not.

Rodyland

@masklinn said:

If such a thing was even remotely possible you'd have languages
translators, and you wouldn't need an XML bloat as middleware agent in
the translation...

Sure. But your language translator would need something 'native' to store the code in. It could choose one of the languages it supports, or it could use its own, custom built language. XML could be its native language, it very likely wouldn't, but the point is it could.

@masklinn said:

XML is not magic you know, just because you translate a program to some XML stupidity doesn't mean you can convert that stupidity back into another language...

I'm not defending XML per-se, and in your haze of XML hate you are missing my point. My point is that this type of idea is, IMO, a possible candidate for next (or next-next) generation languages, either by evolution or revolution. It's the idea - that this XML language is a half-step in the vague direction of meta-programming-languages (if you like), that I'm supporting, not XML, nor it's use as a programming language in this specific instance.

masklinn

@Rodyland said:

Sure. But your language translator would need something
'native' to store the code in. It could choose one of the
languages it supports, or it could use its own, custom built
language. XML could be its native language, it very likely
wouldn't, but the point is it could.

Why the hell would it? XML is for plateform-independant storage of data, the software would take a source in, an input language (if it can't infer the language from the source), an output language, and do the translation. Why would it store anything? Either store the input or the output language, it's not like they're platform dependant themselves and need to be managed as data.

masklinn

@Rodyland said:

I'm not defending XML per-se, and in your haze of XML hate you are
missing my point. My point is that this type of idea is, IMO, a
possible candidate for next (or next-next) generation languages, either
by evolution or revolution. It's the idea - that this XML
language is a half-step in the vague direction of
meta-programming-languages (if you like), that I'm supporting, not XML,
nor it's use as a programming language in this specific instance.

As far as I know, the next-generation meta-programming language has existed for some 35 years or so. It's called Lisp. And it even manages to be slightly more readable than XML with much less redundancy once you get used to S-Expressions.

Rodyland

@masklinn said:

Why the hell would it?

I'm assuming here you're referring to my 'but the point is it could
<use XML as native storage>'. I don't profess to offer any
reasons why it would or wouldn't, should or shouldn't... that seems to
be what you're ranting about, and I don't care.

@masklinn said:

Why would it store anything?

Oh, I dunno, maybe to store it somewhere, for instance? Source control anyone? How about so you can compile it?

@masklinn said:

Either store the input or the output language, it's not like they're platform dependant themselves and need to be managed as data.

If you bother to read what I actually wrote instead of continuing on your 'XML is teh ghey' rant, you'll see that I included your conclusion (store input or output language) as one of my options.

I guess I should clarify for you, as you seem unable to grasp the underlying concept, I'm not talking about a command-line language translator... When I talked about a system that would take code written in one language by me and present it in another language to you, I had an entire IDE-like system in mind. I thought that was implied in my original description, and if not I apologise.

Now, I'm not implementing such a system, but I find it difficult to believe that there would be absolutely no reason whatsoever in the whole wide world for such a system as I've described to store all code in some 'native' format, be it one of the supported languages or its own custom-build language.

Rodyland

@masklinn said:

As far as I know, the next-generation meta-programming language has
existed for some 35 years or so. It's called Lisp. And it even manages
to be slightly more readable than XML with much less redundancy once
you get used to S-Expressions.

.<- Here is my
point........................................................................................
Here is you ->.

My knowledge of Lisp is minimal at best, but, IIRC my uni lectures
years ago where Lisp was mentioned, the ability to translate Lisp into
another language automatically was not mentioned. Maybe I slept
through that bit.

Anyway, I think you're getting too caught up in your raging hatred of
XML and the words that I have used to describe my thoughts, rather than
trying to understand what I'm trying to say. "I know you think
you heard what I said, but I don't think you understood what I meant"
probably sums it up nicely.

Have a nice day.

felix

@masklinn said:

the software would take a source in, an input language (if it can't
infer the language from the source), an output language, and do the
translation. Why would it store anything?

FYI, any software that translates between a number of formats has
to have an intermediate one, otherwise it would require N^2 translators
(from every supported format to every other). With an intermediate
format, you only need 2N translators - a whole lot less. Now, the exact
choice of formats is an entirely different matter...

dhromed

I thought ColdFusion was dead.

Hitsuji

Hehe, got such a headache from reading this post. Too much stupid arguing is always annoying.

That code seems to be a complete ripoff of C#, with a few cock-ups, like assigning values while declaring the int array in the class.

But before that c like language translator thiny, what ever you wanna call it, it was just that bloody mess off an xpp file, and why oh why, would anyone ever consider write code in such a mess when it would be far simpler and a hell of a lot faster just to write it as a normal XML file.

As regards the whole idea of a "universal translator" for programming languages, well thats way off from now, before we see that we'll see decompilers. in order to have a universal translator you do require an intermediate language, but this cant be a high level language for the simple reason that the language would have to be so powerful that it would just become way too bloated and will basically never get finished. There are plenty of suitable languages that have been around for decades, such as assembly, lisp, or even machine code itself. Each of course has its disadvantages as an intermediate language. For example, if you were to translate any 2 languages you would loose all class names, variable names, etc...

However recently as part of the .NET Framework MS have writen a new intermediate language known simply as MSIL(which all .NET applications are compiled to), which would be a very suitable language for translation. As it stores enough information. However even with this there are still a few conflicts, such as VB is not case sensitive, so attempting to translate a c++ app having a class containing 2 vairiables named fooBar and FooBar to VB will have its obvious problems.

On my last note then... XML SUCKS DONKEY BALLZ...

Grovesy

Come on, seriously, xml sucks as a data interchange format, for one simple reason.. it's hierarchical, allows duplicates and requires DDT / XSD / Namespaces to apply any meaning to the data , I recall some guy called Ted Codd has something quite bad to say about hierarchical 'structured' data back in 1979.

There are much better formats out there, the relational model for example express everything as relations containing a header (name, type pairs) and body containing tuples contain components (name, value pairs). Constraints can be expressed very simply, and their is little repetition, and certainly no duplicated data which often gets forced on you in any hierarchical format

don

@Grovesy said:

Come
on, seriously, xml sucks as a data interchange format, for one simple
reason.. it's hierarchical, allows duplicates and requires
DDT / XSD / Namespaces to apply any meaning to the data ...

That's three reasons, by my count:)

Kidding aside, though, I must say I've learned a lot from this thread.
But I still don't quite the main point of the anti-XML army. People
keep saying it's bad because it's not good for this or that...for
instance, several posters have mentioned that it's inherently
hierarchical. Maybe I'm just too ignorant to get my head around this
(I've only been coding professionally for about four years, so I'm kind
of a newbie), but isn't that what it's for? Isn't it all about
representing hierarchical data? Sure, it's not a great choice for all
data, but if your need is to serialize a tree, why isn't this an okay
way to do it?

I certainly agree that anyone who thinks it's a great universal storage
format is getting carried away. One good look at any common database,
say a phone book or a billing history, will surely suggest better ways
to format them than XML. But isn't dinging it for being hierarchical
and therefore not good for everything sort of like dinging a knife for
being sharp and light and therefore not being good for driving nails?
Are we maybe responding to XML Fever rather than to XML?

Suck_My_Lisp

@Rodyland said:

My knowledge of Lisp is minimal at best, but, IIRC my uni lectures
years ago where Lisp was mentioned, the ability to translate Lisp into
another language automatically was not mentioned.

Lisp programs are written using S-expressions, which are lists where
the first element is an operator (macro, function, or
[url=http://www.lisp.org/HyperSpec/Body/glo_s.html#special_form]special
form[/url])

@Rodyland said:

Maybe I slept
through that bit.

Probably wasn't covered. Universities, even the best, almost
never give Lisp its due. The ones that teach it seriously (like
Berkeley and MIT) use Scheme, which is easier to learn but less complex
then (Common) Lisp. The rest teach it like a joke language only
used by recursion fetishists (Common Lisp can loop like no other).

Zlodo

@tofu said:

Obviously you've never written a program to read-in a binary file when
you didn't have the file's definition or any kind of custom libraries
to do it.

I'm currently working on a large project that reuses a lot of code, tools and data formats from a previous similar project. There is some code that is more than 8 years old in there.
There are tons of crappy binary file formats all over the places, tons of code duplication and redundant implementations of similar things, tons of WTFs, and also a fair amount of XML in there.

Ad-hoc binary formats are utterly bad.
However, I think XML is not a good solution. IMO it's only a partially succesful and useful solution, not because it doesn't go far enough, but because it goes in the wrong direction.

The problem is as follows: with binary formats, people spend a lot of time writing crappy writing/reading code, sometimes duplicate it because of bad design that prevent from reusing the same class (along with its serialization code) in two different applications.

One argument I often hear in favor of XML is "you don't need to write a
parser for everything". You still have to parse what SAX or DOM gives
you.
Instead of reading/writing bytes or characters, you're reading/writing xml elements. You still have to map your runtime representation (usually a bunch of interrelated objects) to your xml representation, and to choose a proper structure for your xml file.

And this is true whether you use DOM or SAX (if you use DOM you're additionally wasting tons of memory and time to construct a DOM representation that you then need to reconstruct your actual objects with).

If I have a bunch of data that I want to be able to manipulate from different languages, say for instance C++ and Python, I'd rather create python bindings for my C++ code so that python can reuse all the classes and stuff I wrote in C++. In that case the actual file format used (binary, XML, etc.) isn't quite as important.

But, for instance, in the project I'm working on, there is a place where we need to load and save a hierarchy of objects. Sure enough, the code that does it is specific to the place where it is used, whereas if we had a serialization system that allowed deep-saving graphs of objects (which is not really that hard to do, by the way), it could have been used to just store and reconstruct the object hierarchy without using ad-hoc code.
And what help would XML have been for this ? Marginal.

Basically, what you are working with most of the time when developing an application are objects represented natively in memory in a certain way, and where efforts should be focused IMO is on automatizing the mapping of this to a file representation, not the way the data is represented.

Suck_My_Lisp

Forum Software Sucks

Lame forum software mangled my post. The following paragraphs should have been in there:

An S-expression is a list where the first element is an operator
(function, macro, or special form) and the subsequent elements are
arguments to that operator. Lists are a first class data
structure in Lisp, and there are a lot of built-in functions for
manipulating them, formatting them (the "pretty printer"), etc.
Thus, all Lisp programs are also lists, and can easily be manipulated
in Lisp.

Lisp doesn't include facilities for transforming Lisp to other
languages, but it does include facilities for transforming Lisp into
different Lisp. Its ability to do this is unmatched by any other
language, except Dylan (which is Lisp with a different syntax).
For example, if you wanted a control structure that randomly executed
one statement from a list of them, you could easily extend the language
with this feature:

(defmacro one-of (&rest statements)

`(case (random ,(length statements)

,@(loop for i from 0 and statement in statements collect (cons i statement))))

Then you could write:

(one-of

(print "apple")

(print "bannana")

(print "dog"))

And one of either "apple", "bannana", or "dog" would be printed.

The IT industry is doomed to spend from now until eternity reinventing stuff that Lisp did better.

Suck_My_Lisp

Re: Forum Software Sucks

And now it moved my followup post, that should have gone on to today's wtf, into the start of its own thread. I give up.

This forum was designed by the people we mock.

Suck_My_Lisp

Re: Forum Software Sucks

(I ment the "X++" thread, not today's WTF thread.)

Brendan_Kidwell

Re: Forum Software Sucks

Welcome to thedailywtf.com. You have been initiated now. Not only do you have to lurk for some time--as in other forums--to get a feel for the the tone of the forum, but here you must also post and make several silly mistakes before you are truly initiated and get the feel for the software.

You are now ready to participate.

@Rodyland said:

Anyway, I think you're getting too caught up in your raging hatred of
XML

Repeatedly making this assertion only makes you seem bitter and blind. Come on, he came right out and said XML has its uses in its place, disagreeing with your idea doesn't mean he has a "raging hatred of XML". It's an intermediate format. For god's sake, there's nothing tying XML and this specific implementation, it could be XML or it could be anything else, so shut up already.

There's XML, there's ASN.1, there's bEnc, there's Postscript (most venerable universal interchange formats), there's csv, there's plain text, and of course there's good ol' binary formats. Pick one that suits your application.

Feel free to bitch at stupid people who pick the wrong format, though. =D

As for the history of XML, it is based on HTML. I've used SGML in the past, and several flavors of it are VERY different from html/xml, whereas those two are very similar (the latter is both more strict and more loose, but the overall appearance and style is similar). It's fair to say that XML is a close cousin of HTML. Why did it take so many years to ratify XML, though, when they didn't even bother to change DTDs into something vaguely manageable? It took even more years for the different third-party schemas to catch on, if they'd just had a useful one to start with it could have alleviated a lot of peoples' troubles.

Tofu, I'll have you know that I could recreate that binary format wtf in fully structured xml without severe problems. Creating a wtf format is a snap in any encoding, if you're willing to play tricks and games with storage structure. (Which your guy obviously did.) Conversely, parsing a well planned-out binary format with no compression or space-saving tricks is a snap. That's why save game editors exist for most games.

masklinn

@foxyshadis said:

As for the history of XML, it is based on HTML. I've used SGML in the past, and several flavors of it are VERY different from html/xml

Please. Extracted from the XML specification, 3rd edition:

The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document.

HTML is an SGML dialect just as, say, XHTML or SVG are XML dialects, you can't compare XML and HTML.

jwenting

@Taliesin said:

I had succesfully implemented a multi price list decoder that actually reads data from 19 different providers (45.000 products) and is extensible, allowing the user to add new price-lists, this software would cost my customer a lot more if the data come in other formats like csv, excel or binnary. XML allowed me to cut my programming time, which allowed a lower cost, which finally grant me the contract.

Ever heard of EDI? That's a 30 or so year old standard for talking between disparate machines that does exactly that.

It was designed for having machines talk in a logistical system with different companies (supplier, shipper, receiver, etc.) involved all using different hardware on different software often on narrow pipes.

It uses plain text (fixed format) messages. Like XML, define the message format and as long as everyone talks the same message everyone can use it.

@Taliesin said:

There is another place where XML is perfect: if we want to store user preferences or configurations in scenarios where we traditionally use binnary files. The use of XML in those situations allow the user to manually change those things (we are talking about a software where this is desirable)

Ini files, properties files, such systems have existed for decades. XML makes it more verbose which may make it sometimes easier to read but it certainly isn't groundbreaking in that suddenly something was possible that was impossible before.

Don't get me wrong, there are places where the XML is a valuable tool but it's massively overused.

Worst example of that is when I worked for a major international company and we were handed a directive that had originated at the board of directors (what the heck do those guys have to do with lowlevel IT decision making?) that as of immediate ALL software should use XML.
We immediately had to modify all the software we maintained to use XML at some point, whether it actually made sense or not.
For most applications this took the form of changing some config file or message format to XML, wasting a few hours per application for no purpose except to comply with the directive.

tofu

@foxyshadis said:

Tofu, I'll have you know that I could recreate
that binary format wtf in fully structured xml without severe problems.

I'm sure you could, but you would pretty much have to do that on purpose.

In my story, I had a competent programmer. As far as I know, he
just had a bunch of structs and used some kind of library to write them
to files. He wasn't trying to obfuscate it, but it was obfuscated.

If his libraries had output as XML, my job would have been so much easier. That is just a simple fact.

kierenj

XML programming languages are a new thing?

What about XSLT? It's a functional language, sure, but still a programming language.

Also IMO: XML is good. Doubley so with .NET. I spend all day writing .NET solutions, and the ability to persist a DataSet / DataTable to disk for permanant storage with "WriteXml" or similar is great.

Great because (1) you can directly transform that XML into reports etc using XSLT, (2) its just as easy to make a DataSet appear from nowhere just using "ReadXml" and (3) if it all goes wrong, just open up the XML file - you can read the data in there yourself.

That's what they mean by human-readable. The important thing is that when it comes down to it and there's some issue, you can just open the XML file or access the XML straight from the debugger.

Is there anyone here who can provide an example as to where XML hasn't been useful? i.e. it's hindered them? Plenty of people saying how they don't like it, but have you actually been stumped by a problem that XML has caused? Now, how many people like me have had to run through KB/MB of raw data, CSVs or similar, which cause far more "stumps"..

Zlodo

@kierenj said:

XML programming languages are a new thing?

What about XSLT? It's a functional language, sure, but still a programming language.

Also IMO: XML is good. Doubley so with .NET. I spend all day writing .NET solutions, and the ability to persist a DataSet / DataTable to disk for permanant storage with "WriteXml" or similar is great.

I agree that having a persistence system is a good thing, but you don't need XML to build a persistence system. It would be just as easy to use if it persisted the data in binary, S expression or anything else, hence XML doesn't provide much added value here.

Great because (1) you can directly transform that XML into reports etc using XSLT,

And you can transform anything else into reports using any scripting language. I give you that XML make it a little easier to parse the input, but most of the work is still to make sense of it and restructure it into your report, and unless XSLT is magical, I don't see how it would make it that much easier than another language.

(3) if it all goes wrong, just open up the XML file - you can read the data in there yourself.

I work with binary files a lot in my current project, yet the instances where I actually have to open them in a binary editor to see what they're like are quite rare.
An human-readable format is useful, but you can have it in other ways than XML anyway.

Is there anyone here who can provide an example as to where XML hasn't been useful? i.e. it's hindered them?

Some people here wrote some call-graph and memory usage tools tailored to work with our project. They output XML files.

They are so huge that they are an horrible pain in the ass to extract anything from them. It takes several minutes to open some of them.

It would have been so much better to use a lightweight RDBMs like sqlplus to store this data.

XML doesn't scale well when manipulating large amounts of data. Therefore, choosing XML over something else can often be a dangerous idea.

I could also mention that we have a lot of small XML files. We use TinyXML (a small and nice C++ DOM implementation).

We're often loading a lot of these files. It is slow and it leads to a lot of unecessary copying and messing around with the data in memory to turn the DOM into the bunch of objects we're actually using. It also leads to allocating and freeing lots of memory blocks, which is a big performance turnoff.

Again, it's caused by solutions that look sexy at first glance, and the "well they provide tools, let's trust them that these are good tools and just use them" mentality. XML is actually full of traps like that, and the amount of people always heralding it as the bestest possible way to store data isn't helping.

Also, I could mention problems caused by the "XML is a silver bullet" mentality in a previous company I worked for.

We were developping two games, one on PS2/Gamecube, the other one on Gameboy advance. Both were similar adventure games (obviously with very different representations).

We made a custom scripting language for the GBA version (I would rather have used lua, but some people there had decided that it wasn't efficient enough...).

The PS2/Gamecube team decided to use the "Universal XML solvent" on the problem and to just throw together a finite state machine engine, and use a XML description thereof as a scripting language.

Defining a simple interaction like making so that moving a lever would open a door took like 3 lines in our script language.

It took them something like two pages of XML. And they also had to build a system to store the XML data as binary files because the parser was wasting too much memory/cpu time for the game consoles.

@Zlodo said:

And you can transform anything else into reports using any scripting language. I give you that XML make it a little easier to parse the input, but most of the work is still to make sense of it and restructure it into your report, and unless XSLT is magical, I don't see how it would make it that much easier than another language.

XSLT's real magic is XPath, which is quite useful for quickly and simply querying heigharchial structures like XML. Similar to ldap, but easier to use. (Unfortunately hindered a bit by some shortcomings of XSLT, but it is usable in other languages.) The functional aspects are just a nice touch for working with some types of data.

I could also mention that we have a lot of small XML files. We use TinyXML (a small and nice C++ DOM implementation).
We're often loading a lot of these files. It is slow and it leads to a lot of unecessary copying and messing around with the data in memory to turn the DOM into the bunch of objects we're actually using. It also leads to allocating and freeing lots of memory blocks, which is a big performance turnoff.

I have no idea how anyone can actually use DOM. It's a never-ending stream of bugs to squash, better (but slower) to use XPath, especially in conjunction with an optimized read-only DOM like Xerces/Xalan's DTM. Assuming XML is even desirable (or unavoidable).

It took them something like two pages of XML. And they also had to build a system to store the XML data as binary files because the parser was wasting too much memory/cpu time for the game consoles.

I bet they rolled their own and spent days debugging it. Heh, the XML working group's flat refusal to define a binary format has contributed to companies' problems and a proliferation of non-standard formats. The most useful one I know of is EBML, although it's not 100% compatible (no DTDs or XSI) and I haven't researched many others.

wmil

In defense of XML

A lot of people complain about XML. Just remember that things could be a lot worse. ESRI makes mapping software and has a plaintext format for import/export. There's some unofficial documentaion on it.

It contains gems like this: <blockqote>

TX6, TX7, RXP and RPL sections start with the usual "TX6 2", etc. line, and end with "JABBERWOCKY".

Because after all, data formats are the best place to show your love of Lewis Carroll.

TGV

Re: In defense of XML

I'm sure there is a perfectly acceptable explanation for this jungle of formats (really, if you haven't looked at the page, do it, it contains more gems). One explanation could be that the first format was created in the early 50's when punch cards were da bomb. After that, each new requirement/feature resulted in a new file format, defined by a junior programmer that had been kept away from the project, hidden in a dark closet, kept alive on a diet of twinky bars and Pepsi Max. Later, his diet might have included smart drugs.

Another explanation could be that new file formats were defined by copying the parser of one of the existing file formats, and changing a few lines at random, and then trying to figure out how to avoid the parser from crashing.

Anyway, I think they might have pulled the same trick in XML:
<

TGV

XML codew

GalacticCowboy

I'm pretty sure it should look something like this:

</DIDGYREANDGIMBLE>

</ANDTHESLITHYTOVES>

</TWASBRILLIG>

</JABBERWOCKY>

dhromed

In XML, tagnames are lowercase.

masklinn

@dhromed said:

In XML, tagnames are lowercase.

They're case-sensitive, no one stops you from creating a fully uppercase XML dialect if that's what turns you on.