Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Celebrate the XML Decade

CowboyNeal posted more than 7 years ago | from the happy-birthday dept.

177

IdaAshley writes "IBM Systems Journal recently published an issue dedicated to XML's 10th anniversary. Take a look at XML application techniques, and general discussion of the technical, economic and even cultural effects of XML. Learn why XML has been successful, and what it would take for XML to continue its success."

cancel ×

177 comments

Sorry! There are no comments related to the filter you selected.

Re:Celebrate the XML Decade (4, Funny)

eldavojohn (898314) | more than 7 years ago | (#16879658)

Celebrate the XML Decade
I tried. Oh Lord, how I tried!

I started this morning by talking to everyone in XML.

I hope the black eye my coworker gave me heals before my presentation to the CTO tomorrow morning :-(

Re:Celebrate the XML Decade (-1, Troll)

dubbayu_d_40 (622643) | more than 7 years ago | (#16879938)

Maybe you should get another job dumbass.

Re:Celebrate the XML Decade (4, Funny)

Duhavid (677874) | more than 7 years ago | (#16880022)

Really...

We all needed to leave the first post in this to the guy with
the sig

"XML is like violence, if it doenst fix the problem, you arent using enough"

Or words to that effect.

Re:Celebrate the XML Decade (3, Insightful)

Dahamma (304068) | more than 7 years ago | (#16881356)

Someone put that in our Bugzilla quips a while back - it's still one of my favorites!

My conspiracy theory is that XML was secretly invented by Intel in order to require 3GHz processors for the simplest of tasks.

Re:Celebrate the XML Decade (4, Funny)

Randolpho (628485) | more than 7 years ago | (#16880262)

I started this morning by talking to everyone in XML.
<conversation>
<greeting type="friendly">Hello, fellow coworker type dude!</greeting>
<response type="violent">Have a black eye!</response>
</conversation>

Re:Celebrate the XML Decade (4, Funny)

Anonymous Coward | more than 7 years ago | (#16880382)

<greeting type="friendly">Hello, fellow coworker type dude!</greeting>
That's a poorly designed format. You should make "greeting" a complex type and use elements to represent the greeting text and the greeting type. Then, the greeting type can be properly validated against a W3C XML Schema. There's no valid reason to use an attribute in cases like these.

Are you autistic? (0)

Anonymous Coward | more than 7 years ago | (#16880470)

Uncyclopedia needs more editors like you.

Re:Celebrate the XML Decade (4, Funny)

zootm (850416) | more than 7 years ago | (#16881764)

That's a poorly designed format. You should make "greeting" a complex type and use elements to represent the greeting text and the greeting type. Then, the greeting type can be properly validated against a W3C XML Schema. There's no valid reason to use an attribute in cases like these.

I took the liberty of revising the format a little, is this better?

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<conversation
xmlns="http://slashdot.org/sarcasm/XML/conversatio n"
xmlns:html="http://www.w3.org/1999/xhtml">

<participants>
<participant>
<short-name>OP</short-name>
<full-name>Original poster</full-name>
</participant>
<participant>
<short-name>CW</short-name>
<full-name>Unwitting coworker</full-name>
</participant>
</participants>

<relationships>
<two-way-relationship name="coworker">
<person>OP</person>
<person>CW</person>
</two-way-relationship>
</relationships>

<greeting time="2006-11-17T10:12:10Z" speaker="OP" targets="CW">
<type>
<demeanour>friendly</demeanour>
</type>
<speech>
<text type="text/plain">
Hello, fellow coworker type dude!
</text>
</speech>
</greeting>

<response time="2006-11-17T10:12:34Z" speaker="CW" targets="OP">
<type>
<demeanour>angry</demeanour>
<context>
<divorce type="messy"/>
<custody-battle type="messy"/>
</context>
</type>
<speech>
<text type="application/xhtml+xml">
Have a <html:em>black eye</html:em>!
</text>
</speech>
<action>
<punch>
<recipient>OP</recipient>
<aim>eye</aim>
</punch>
</action>
</response>

</conversation>

I'm sort of disappointed that I only got to use two namespaces. Can't get indentation to work either, unfortunately.

XML Debacle is more like it ;) (2, Funny)

FooAtWFU (699187) | more than 7 years ago | (#16880384)

Actually, I was looking at the title and I did a double-take, since the first time I saw it I thought it said "Celebrate the XML Debacle". Oop. I thought, surely it's not that bad...

Eh, what do I know? Maybe it is that bad. =)

Re:Celebrate the XML Decade (3, Funny)

gbobeck (926553) | more than 7 years ago | (#16881464)

I started this morning by talking to everyone in XML.

Care to share the DTD and schema you used for that?

Half-Life 7? (1, Offtopic)

PriyanPhoenix (900509) | more than 7 years ago | (#16879690)

From TFA:
It goes on to give HL7 as an example of such a modeling approach.
Wow, they really do think XML has staying power! By my count Half-Life 7 is due to land sometime 2097...

Re:Half-Life 7? (2, Informative)

Anonymous Coward | more than 7 years ago | (#16880144)

HL7 [hl7.org] is a "standard" for moving patient information from system to system. I call it a "standard" because the 1.x and 2.x versions were largely "advisory", with more MAY than MUST, with a huge amount of wiggle room... I've worked on 4 information exchange projects now, and all of them started from scratch because none of their HL7 "specs" are compatible.

Supposedly the new version 3 standard (which uses the "modeling approach") will be much more firm with the implementors, which will hopefully mean that every now and then one implementation will actually be compatible with another implementation. I've looked over their "models" and they've modelled a lot of the business use-case stuff for patient data, but not a lot of the actual data itself. Hopefully when it's done, it'll come out a bit better baked than previous versions.

Why XML was successful (3, Insightful)

Ant P. (974313) | more than 7 years ago | (#16879730)

Marketing to PHBs, mostly.

However here on earth a lot of people still hand-code the stuff. IMO a C-like syntax using nested {}s would've been better.

Re:Why XML was successful (4, Informative)

MP3Chuck (652277) | more than 7 years ago | (#16879812)

"IMO a C-like syntax using nested {}s would've been better."

JSON [wikipedia.org] ?

Re:Why XML was successful (1, Informative)

Anonymous Coward | more than 7 years ago | (#16880354)

And if anyone's under any illusion that JSON isn't try to reimplement XML I'd like to introduce you to JsonT [goessner.net] ... JSON Transformations.

Re:Why XML was successful (1)

Carewolf (581105) | more than 7 years ago | (#16881654)

You know there is an entire programming language designed to manipulate JSON datastructures, a language that quickly pentrating all of the web.

It is known as: JavaScript

Re:Why XML was successful (0)

Anonymous Coward | more than 7 years ago | (#16881824)

JSON datastructures... via XMLHttpRequest when all browsers have already parsed it into an XML Document. So basically what JSON gets you is object serialization/deserialization -- a nicer API to copy details out of. XML's equivalent is E4X, or any of the wrapper libraries that allow XPath to object hierarchy mapping, and they can be used for innerHTML and other uses unlike JSON. JSON is good for object mapping, but that's only a small part of AJAX/XMLHttpRequest

Re:Why XML was successful (5, Interesting)

Ankh (19084) | more than 7 years ago | (#16880588)

A lot of people ask about using a different syntax, such as @name{....} as Scribe (and later LaTeX) did. Note that @element{xxx} is in fact a possible syntax that can be defined using SGML. But we were after something different.

When we designed XML, we had over a decade of solid experience with interoperability in the world of SGML, and we also knew about the kinds of problems that different sorts of users had with different sorts of syntax.

The primary users of SGML-based documentation systems were not programmers. They were people who were often not likely to know about a bracket-matching option in an editor or about code indenting, for example. But they were still legitimate users.

You can't easily test the markup in a declarative system: if in an HTML document I used H3 instead of P in a document it might not look right, but it would still parse OK. If I muddle up Author and Title in a bibliography, same thing.

So, the redundancy of end tags in XML is there because, in practice, if you didn't have it, we had learned that our users had problems correcting their documents, and we knew that, in general, it was only rarely possible for software to give the users much help. There were some experiments early on with </>, allowed by SGML (with various options set) to end any element; it soon became obvious that this caused more problems than it was worth, and even Microsoft disabled the troublesome feature in their XML parser.

It's true that today XML is used in lots of situations we didn't predict. We were amazed that by the time we got XML published as a Recommendation there were over 200 users. So no, we didn't predict the future percfectly. But the popularity of XML shows we can't have done all that badly, really ;-)

Liam

(Liam Quin, currently W3C XML Activity Lead)

Re:Why XML was successful (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#16880720)

To my mind this whole argument about wanting to have "human readable/friendly syntax" for XML is total nonsense.

We didn't need a human accessible format. We needed a regular format. Once we have that, we can then write applications to edit and display it in any way that the humans want. To make XML human readable is to mix presentation layer issues, with encoding issues.

So I like the idea of XML, just not the particular choice of syntax. We should have just used Lisp syntax, since then we would have had parsers for it in 5 mins of coding.

Human readable & writable does matter (1)

Geof (153857) | more than 7 years ago | (#16880982)

We didn't need a human accessible format. . . . we can . . . write applications to edit and display it in any way that the humans want. To make XML human readable is to mix presentation layer issues, with encoding issues. . . . We should have just used Lisp syntax, since then we would have had parsers for it in 5 mins of coding.

You know, I like Lisp S-expressions better too. They sure are easier to parse. But, to echo your argument, we have libraries for that, right?

Decades of experience have shown the benefits of human-readable (and writable) formats, for programmers and non-programmers alike. I'll focus on the non-programmers, because in the end they're the ones creating the documents that are the object of the whole exercise.

Non-programmers author XML all the time. They do it because hand-authoring offers flexibility and power beyond what their applications offer them. They do it because they don't have the applications, or they can't afford them. They do it because innovation comes first, the tools come after. They do it because they're hacking FOAF or RSS or a Creative Commons license onto their web site. They will increasingly do it because when the application is obsolete, the data isn't.

If Mr Quin is right (I don't know, I haven't seen the research), your proposal exchanges long-term access for document authors with a bit of up-front convenience for library developers. In my opinion, that's exactly the wrong trade-off to make.

Re:Human readable & writable does matter (1)

jibjibjib (889679) | more than 7 years ago | (#16881530)

when the application is obsolete, the data isn't.

<sarcasm>Yes, because of course by the time your application is obsolete we will have an uber-cool AI that can automagically work out what all your tags meant and convert your XML document to the latest format.</sarcasm>

It's not like just because something's in XML that automatically makes it easily usable with new applications. Converting an old XML format to a new XML format can be just as hard as converting an old binary format to a new one.

Re:Human readable & writable does matter (1)

zeromorph (1009305) | more than 7 years ago | (#16881780)

It's not like just because something's in XML that automatically makes it easily usable with new applications.

Ok, but suppose you have to convert a text file into a semantically structured file.
Please choose your preferred source format:

[ ] unstructured ASCII text file

[ ] XML-file

[ ] MSWord .doc

Re:Human readable & writable does matter (1)

Decaff (42676) | more than 7 years ago | (#16881872)

It's not like just because something's in XML that automatically makes it easily usable with new applications. Converting an old XML format to a new XML format can be just as hard as converting an old binary format to a new one.

As someone who has been involved in having to convert old binary formats, can I say..... this is way out.

Given an undocumented text format with readable markup which can be transformed with a standard mechanism (XSLT) and in any of hundreds of tools, or an undocumented binary format.

I know which I would choose.

Re:Why XML was successful (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16880992)

Separating out human-readableness is fine in theory, but in practice having the lowest-level data in an easy-to-read format proves invaluable from time to time.

Developing a widget that connects to another XML-spewing widget using an XML-reader is all well and good when everyone behaves. But more often than should happen, the other widget uses some syntax or formatting that's improper XML or your XML-reader-editor can't handle a particular case it uses. Yes, in a perfect world, both of these would follow the standard perfectly and you'd never have to look at the formatting, but when I'm getting paid to code, I often don't have the time or access to the source code to make everything else perfect, and just need to make my code work. If that means relying on notepad on a client's computer, XML's human readability becomes more valuable to me than any presentation-encoding separation.

-TheJorge, posting AC from a friend's computer because firefox saved my password long ago and I can't remember it...

Re:Why XML was successful (0)

Anonymous Coward | more than 7 years ago | (#16881482)

So your argument is it is good that XML has a verbose and complex syntax, because sometimes you need to debug components that have trouble writing or reading such a verbose and complex syntax?

You don't think that perhaps if those components could communicate in a simpler syntax, you wouldn't need to debug them?

Re:Why XML was successful (2, Insightful)

thsths (31372) | more than 7 years ago | (#16881168)

> So, the redundancy of end tags in XML is there because, in practice, if you didn't have it, we had learned that our users had problems correcting their documents, and we knew that, in general, it was only rarely possible for software to give the users much help. There were some experiments early on with , allowed by SGML (with various options set) to end any element; it soon became obvious that this caused more problems than it was worth, and even Microsoft disabled the troublesome feature in their XML parser.

Given my experience with users that have inadequate support in their editor for structured documents, having the redundancy actually does not help. Sure, you get an error message instead of accidentally specifying something you did not wont, but the error message does not help people all that much. So they still stare at the XML and don't get what is wrong.

Allowing comments within an element (for each attribute) would have been a huge contribution to legibility. Of course that depends on how you use it, but I think attributes get a lot of use exactly because they have less redundancy.

My conclusion is that in the end, you need structured tools for structured data. And so the format does not actually have to be easy to read. (And believe me, even the best of XML documents are not easy to read if the structure is reasonably complicated.)

Re:Why XML was successful (0, Troll)

master_p (608214) | more than 7 years ago | (#16881800)

They were people who were often not likely to know about a bracket-matching option in an editor or about code indenting, for example. But they were still legitimate users.

WTF? So just because some users couldn't figure out how to turn on parenthesis or bracket matching in their products, you ended up with the mess that is XML?

There you have it people, straight for the horse's mouth: our civilization [astrodigital.org] is actually based on random poorly thought-out decisions made by a few almost-ignorant fellows.

If we take into account how lame most of the software products are, (for example: how many holes there are in C-based apps, how lame XML is, how horrible WIN32 is, how bad socket APIs are, how complex J2EE is etc), then we ought to be ashamed of ourselves as humanity...and of course with such badly designed software, the sky is not the limit...

Re:Why XML was successful (4, Insightful)

porkThreeWays (895269) | more than 7 years ago | (#16879842)

Sorta... XML came at a time when there weren't a whole lot of good viable data representation standards. Those that did (i.e. SGML) were too complicated for light use. XML was meant to be used by the masses while still technically remain an SGML subset. We have better alternatives today, but once something is in widespread use, it's not going away for awhile.

Re:Why XML was successful (1)

Raenex (947668) | more than 7 years ago | (#16881762)

What are the better alternatives?

Re:Why XML was successful (1)

Decaff (42676) | more than 7 years ago | (#16881866)

We have better alternatives today

Such as?

Re:Why XML was successful (1)

CaptainPinko (753849) | more than 7 years ago | (#16879886)

I keep hearing this and it sees foolish every time. If you just used {} how would you easily tell which tag you were closing? It would be too easy to mistake one brace for another, especially when there are several tags. Sure it'd be more efficient: but the idea was to have something that was equally readable by machines and humans. You take any non-trivial piece of XHTML or other XML and convert it to your new {} syntax. Then go try to add some more mark-up to it. And to non-technical users it would be even more confusing. At my work developers send XML for our business analysts to confirm the output. The only thing I have a qualm with in XML is the use of different >??< >!< tags.

And to another posters complaint about JEE and an over alliance: if you've got meta-data already and are going need a text file isn't it best to have a consist industry-standard mark-up between them? The whole point of meta-data is not to have content outside of code. If you don't want to have content outside of code then just avoid using those systems like Spring. In JEE aside from your web.xml you don't need any at all.

Re:Why XML was successful (2, Funny)

theodicey (662941) | more than 7 years ago | (#16880026)

It would be too easy to mistake one brace for another, especially when there are several tags

I hack LISP, you insensitive clod!

Re:Why XML was successful (1)

Ant P. (974313) | more than 7 years ago | (#16880028)

People seem to have coped fine reading code without closing tags for the past 30 years.

Re:Why XML was successful (4, Insightful)

smallpaul (65919) | more than 7 years ago | (#16880132)

A curly brace syntax would have been a better format for "large scale enterprise publishing"? As someone who has spent more than a decade in that field, I must disagree strongly. A curly brace would have been better to allow enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. [w3.org] Please do not confuse what XML is used for with what it was designed for. There is a reason that XML delivery units are called "documents" and not "messages".

Re:Why XML was successful (1)

binaryloc (1028364) | more than 7 years ago | (#16880136)

Agreed, alot of the new markup-oriented languages really get on my nerves. Worse is the dream weaver groupies who 'use' them

Re:Why XML was successful (0)

Anonymous Coward | more than 7 years ago | (#16880270)

The problem with } to close nodes is that you can't see which element you're closing, which XML does specify.

Unfortunately I'm a Java developer... (4, Funny)

d3ik (798966) | more than 7 years ago | (#16879734)

... and most "enterprisey" Java developers have never met a problem that couldn't be fixed with more XML.

Re:Unfortunately I'm a Java developer... (1)

ashultz (141393) | more than 7 years ago | (#16880214)

That gets my goat too.

Nothing makes a set of code harder to deal with than taking half of it and writing it in a variety of XML config files and then scattering them throughout the distribution. That way you ensure that anyone doing something foolish like trying to understand it through javadoc or use their IDE to learn it gets nowhere.

I'm going to go cry now.

Re:Unfortunately I'm a Java developer... (5, Interesting)

dch24 (904899) | more than 7 years ago | (#16880276)

My bosses were wary when I suggested XML as our data representation for a new project. Here were some of the arguments:

Pro
  • Easy to change the schema, don't have to convert old data.
  • They didn't know exactly what XML was, so if I recommended it, ... (a.k.a. "gee whiz" factor?)
  • The other developers liked the idea
Con
  • They weren't sure whether this would increase (better system = save time?) or decrease (reinvent the wheel = waste a lot of time in meetings?) productivity
  • Takes lots of space (no "binary XML")
  • Slow processing, right? (see "Takes lots of space")

Eventually we settled on gzipped xml. It required a little more code, but everyone seemed happy. Oh, and we stored images as separate .png.

I think my experience is pretty common, though. And from experience, libxml2 + libz is still very, very fast, and there's not a (whole lot) of wasted space.

I'd like to hear other people's success stories, if anyone wants to reply... I liked reading the article, too.

Re:Unfortunately I'm a Java developer... (5, Interesting)

j. andrew rogers (774820) | more than 7 years ago | (#16881266)

The "slow processing" is caused by more than taking a lot of space. XML is basically a document markup but is frequently and regular used as a wire protocol, which has very different design requirements if you want a good standard. And in fact we already have a good standard for this kind of thing called "ASN.1", which was actually engineered to be extremely efficient as a wire protocol standard. (There is also an ITU standard for encoding XML as ASN.1 called XER, which solves many of the performance problems.)

Arguably the single biggest problem with XML that causes slow processing is that software can predict almost nothing about an XML stream and therefore has to allow for anything. The opening bracket tells you very little about what to expect, and creates few implicit failure or non-conformance tests that allows one to terminate processing because there is no definition of "unreasonable". If I want to embed a terabyte of data between XML tags, there is no built-in basic mechanism to inform the software of how much data I should expect to see before a closing tag and no basic mechanism to cue the software as to the type of data to expect. (Yes, you can sort of do it with lots of other layers strapped on, but it isn't core and strapping it on adds complexity.) This is the primary reason it gives miserable performance as a wire protocol format -- the software cannot make decisions about the data without slurping most or all of it, with no way to predict what "most" or "all" actually is. In well engineered standards such as ASN.1, they use the good old tag-length-value (TLV) format. The "tag" tells you what to expect, the length tells you how many bytes to expect, and the value is the actual data. In short, the encoding tells the software exactly what it is about to do before it does it in enough detail that the software can make smart and performant handling decisions.

The only real advantage XML has is that it is (sort of) human readable. Raw TLV formatted documents are a bit opaque, but they can be trivially converted into an XML-like format with no loss (and back) without giving software parsers headaches. There is buckets of irony that the deficiencies of XML are being fixed by essentially converting it to ASN.1 style formats so that machines can parse them with maximum efficiency. Yet another case of computer science history repeating itself. XML is not useful for much more than a presentation layer, and the fact that it is often treated as far more is ridiculous.

Re:Unfortunately I'm a Java developer... (1)

thesnide (640733) | more than 7 years ago | (#16881680)

The only real advantage XML has is that it is (sort of) human readable


I'm all in favor of YAML [wikipedia.org] , that's really human readable,

Re:Unfortunately I'm a Java developer... (1)

master_p (608214) | more than 7 years ago | (#16881814)

The only real advantage XML has is that it is (sort of) human readable.

Actually, it is not. Many people I know, and me, have trouble looking at XML config files that span more than a few rows. You need a tool that presents the XML document as a tree, so you can collapse some nodes in order to focus in the interesting ones.

Re:Unfortunately I'm a Java developer... (0)

Anonymous Coward | more than 7 years ago | (#16881856)

XML itself has no native support for it but obviously you could use a SAX parser and include tags or attributes to specific node content length. If you're going to complain about it's use as a protocol (eg XMPP) it's more the single root tag that makes it difficult.

XML "Sucks" (-1)

Anonymous Coward | more than 7 years ago | (#16879748)

Yeah, let's celebrate reading some interesting opinions about XML [slashdot.org] .

Re:XML "Sucks" (3, Funny)

MyLongNickName (822545) | more than 7 years ago | (#16879918)

When does a broken link constitute "Informative"?

Re:XML "Sucks" (5, Funny)

Bob54321 (911744) | more than 7 years ago | (#16879948)

This is slashdot. Nobody reads the links.

Just in time for the festive season (5, Funny)

Centurix (249778) | more than 7 years ago | (#16879760)

This year I'll be sending out christmas cards in XML and then placing a large banner outside my house with the appropriate schema.

Then with every following year, I'll be sending a stylesheet card which they can apply to the original XML.

And if they need to locate their names on the card, they can use //recipient[@name='mum']

No mention of XML's creators? (3, Informative)

elving (133577) | more than 7 years ago | (#16879766)

Strange that an article celebrating XML [w3.org] 's anniversary would neglect to mention XML's creator [tbray.org] . I wonder if the fact he works for a competitor [sun.com] has anything to do with it...

Re:No mention of XML's creators? (5, Informative)

tbray (95102) | more than 7 years ago | (#16880714)

I have to do this once per year or so, here's the 2006 iteration: I am not XML's inventor. There were 150 people in the debating society and 11 people in the voting cabal and 3 co-editors of the spec. Of the core group, I (a) was the loudest mouth, (b) was independent so I didn't have to get PR clearance to talk, and (c) don't mind marketing work.
-Tim

Don't feel too bad, Tim (4, Funny)

jlowery (47102) | more than 7 years ago | (#16880936)

Al Gore declaims the same every anniversary of the Internet.

Re:No mention of XML's creators? (1)

x2A (858210) | more than 7 years ago | (#16881346)

you're too modest ;-)

A decade of bloat. (1, Informative)

Anonymous Coward | more than 7 years ago | (#16879772)

All we can celebrate is a decade of bloat. For hard drive manufacturers and bandwidth providers, this has been a great development. But for those of us who have to deal with systems that use XML, we often wish that they had chosen a far more compact representation.

S-expressions, of the sort used in Common Lisp and Scheme, would have been a good alternative. They're simple, use a minimal number of characters, and are very easy to parse. Hell, most Comp Sci grads have written at least once such parser during their education.

The worst use has perhaps been with AJAX. Had AJAX been based around data passed as sexprs rather than as XML, it would consume much less bandwidth, and could be handled far quicker on the server side. Unfortunately, a poor technical decision was made to use XML. And so we get to hear all about the performance problems people experience with AJAX systems.

Re:A decade of bloat. (0)

Anonymous Coward | more than 7 years ago | (#16879884)

Keep in mind a lot of Ajax software actually uses JSON, which can mean much fewer bytes getting passed across the wire.

Anything storing data on disk though - yeah, probably best off using XML. At least it's standardized, easy to write up a DTD for most documents by hand (or by using a web-based DTD generator).

JSON itself is still quite bloated. (0)

Anonymous Coward | more than 7 years ago | (#16879980)

JSON itself still suffers from much bloat, and aren't always easily readable by humans. That's why we have additional structured data formats, including YAML [yaml.org] .

Re:JSON itself is still quite bloated. (3, Insightful)

Duhavid (677874) | more than 7 years ago | (#16880070)

Not all XML is readable by humans.

The formatting strings in Janus controls come to mind.

I have heard that the new Office format (XML) was pretty unreadable.

And what is with modding everything in this thread to zero.

Re:JSON itself is still quite bloated. (1, Interesting)

Anonymous Coward | more than 7 years ago | (#16880452)

XML and JSON are typically sent via servers that understand GZIP compression, which means they're only bloated at either end of the wire (the server and the client). Clients have enough memory to store even 100KB of XML (and that's a ridiculous scenario -- few Ajax apps send that much and people send much more HTML than they do XML and no one complains about that). So then it comes down to server resources, and whether 100KB or whatever is going to matter to a server. IMO the complaints seem to be unwarranted (by all means though if someones got a good scenario let hear it).

Re:A decade of bloat. (1)

EvanED (569694) | more than 7 years ago | (#16880502)

S-expressions, of the sort used in Common Lisp and Scheme, would have been a good alternative. They're simple, use a minimal number of characters, and are very easy to parse. Hell, most Comp Sci grads have written at least once such parser during their education.

This article [prescod.net] argues the other side of that point. I'm not sure how convincing it is, but there are at least some benefits to the XML approach. Where the balance falls, I don't know.

XML for English, S-Expressions for Data (0)

Anonymous Coward | more than 7 years ago | (#16880834)

The argument was that English text looks better in XML than in S-Expressions, and few would deny that. But XML has since grown to be the universal data encoding format, and there S-Expressions are far better. Compare:

        (list 1 3 5 7 9)

        <list>
                <element type="integer">1</element>
                <element type="integer">3</element>
                <element type="integer">5</element>
                <element type="integer">7</element>
                <element type="integer">9</element>
        </list>

So if one format is to be chosen for everything, XML is a poor choice. (BTW, XML is ambigous about the semantics of the extra whitespace the the list presentation above.)

XML's Existing (0, Offtopic)

Inmatarian (814090) | more than 7 years ago | (#16879824)

XML exists so that the "version" field in binary files doesn't spill over to the next byte, making it impossible for old software to interpret new features. But hey, lets give a round of applause for XML. It makes manual corrections a lot easier than wipping out a reference file and a hex editor.

Re:XML's Existing (2, Interesting)

myrdred (597891) | more than 7 years ago | (#16879908)

<?xml version="1.0"?>
<content name="Shameless Self Promotion">

Good point, though there's a better way to edit binary files.

For example, I make a product called FileCarver which allows you to create a file format definition (in XML! heh), that describes the format of a binary file, and the program will automatically provide you with a GUI to edit it. Check it out at http:/fizzysoft.net/filecarver/

</content>

news flash (1, Insightful)

User 956 (568564) | more than 7 years ago | (#16879828)

Take a look at XML application techniques, and general discussion of the technical, economic and even cultural effects of XML.

Cultural Effects? This is a spec for structuring data, not a Picasso.

Re:news flash (1)

grcumb (781340) | more than 7 years ago | (#16879894)

Take a look at XML application techniques, and general discussion of the technical, economic and even cultural effects of XML.
Cultural Effects? This is a spec for structuring data, not a Picasso.

Philistine. You just don't appreciate abstraction.

8^)

Re:news flash (1)

kfg (145172) | more than 7 years ago | (#16879932)

This is a spec for structuring data

No, it's a spec for text markup.

Cultural Effects?

Rampant spec abuse. 10 years old and still looking for a problem to solve.

KFG

Re:news flash (1, Funny)

Anonymous Coward | more than 7 years ago | (#16880234)

"No, it's a spec for text markup."

"First, in spite of it's name, XML is not a markup language; rather it's a toolkit for creating, shaping, and using markup languages."
[Source: ISBN:0-596-00046-4]

"Rampant spec abuse. 10 years old and still looking for a problem to solve."

Then don't use it. I'm certain your indian replacement will not have any such issues.

Re:news flash (1)

kfg (145172) | more than 7 years ago | (#16880538)

"First, in spite of it's name, XML is not a markup language. . .

OK[delimiter],[/delimiter] so now it's a spec so bad they even named it wrong and a standard data exchange format with no standard[stop].[/stop] [sarcasm]Muuuch[/sarcasm] better[fullstop].[/fullstop]

I'm certain your indian replacement will . . .

. . .be a hell of a shock to my family.

KFG

KFG

Re:news flash (1)

macadamia_harold (947445) | more than 7 years ago | (#16880760)

No, it's a spec for text markup.

Oh, so text isn't "data"?

idiot.

Re:news flash (1)

kfg (145172) | more than 7 years ago | (#16880976)

It's also a binary format.

KFG

My apologies; I went off on a slight tangent there (1)

kfg (145172) | more than 7 years ago | (#16881178)

A more accurate answer to your question would be:

lkajt;oq iuj4 tylkmeafngm/lahtoi[quypitjnqw;lkrgejq;lk

KFG

Re:news flash (1)

l0b0 (803611) | more than 7 years ago | (#16881454)

Maybe he was thinking about IT culture. XML sure has gotten rid of a lot of maintenance problems with regard to computer parsed files. Don't put the format description and instructions in a manual; blend it with the data!

Anyway, fundamental technological changes always have some impact on the rest of society. GUIs made computers accessible outside of academic circles, the Internet made the world talk, and using XML can be a small step towards more people understanding your data the same way you understand it.

XML Decade? (5, Funny)

RealGrouchy (943109) | more than 7 years ago | (#16879954)

Wait... let me figure this one out...

MCMXC was 1990...
MDCCCLX was 1860...

I give up! Which decade was XML?

- RG>

Re:XML Decade? (1)

Werkhaus (549466) | more than 7 years ago | (#16879994)

>I give up! Which decade was XML?

Sixties. Unfortunately, it was the 1060s.

Re:XML Decade? (1)

Planetary (1024995) | more than 7 years ago | (#16881518)

> Sixties. Unfortunately, it was the 1060s.

That would be MLX, actually.

Re:XML Decade? (1)

guruevi (827432) | more than 7 years ago | (#16880024)

Converting XML to Decimal is 1060. Long time ago ;-)

Re:XML Decade? (3, Informative)

Anonymous Coward | more than 7 years ago | (#16880110)

Actually, that would be 1040 -- 'X' (10) before 'M' (1000) = 990 + 'L' (50) = 1040

Re:XML Decade? (1)

Anonymous Coward | more than 7 years ago | (#16880850)

Yes; 1060 would be MLX.

950 AD (0)

Anonymous Coward | more than 7 years ago | (#16880044)

XML == 950 10/1000/50 (low numbers, before high numbers subtract,--IV=4, IX-9, etc.)

Re:950 AD (0)

Anonymous Coward | more than 7 years ago | (#16880158)

It would actually be 1040

10/1000/50 - 1000-10+50 = 1040.

Still, it's not standard; MXL would be the usual form.

So where is this old chestnut? (1)

Cosmic Debris (650504) | more than 7 years ago | (#16880042)

I don't know the origin of the saying but it brings to mind something I use when discussing the subject with customer architects:
XML is like violence. If it doesn't work, you're not using enough of it.
If anyone can come up with the true source of this -- or the accurate quote -- I'd appreciate it.

Re:So where is this old chestnut? (1)

19thNervousBreakdown (768619) | more than 7 years ago | (#16880316)

It flows better this way, and I think it originally referred to sex instead of XML:

XML is like violence. If it's not solving your problem, just use more.

Re:So where is this old chestnut? (0)

Anonymous Coward | more than 7 years ago | (#16881536)

Seen a year-or-so ago:

--
XML is like violence: if it doesn't work, use more.
sig for timc on wwiionline.com, Sep 2004
--

XML is what it is (1)

mlwmohawk (801821) | more than 7 years ago | (#16880050)

Can we forget the hype, can we forget the PHBs, can we forget all the nonsense?

XML has a purpose, combined with expat, it is a convenient, if inefficient, method by which programs can exchange data relatively easily.

I am not an XML fan, by any means, but if absolute efficiency is not important, XML provides a common format for data exchange.

Stuck (2, Insightful)

Duncan3 (10537) | more than 7 years ago | (#16880052)

So we're officially stuck with this crap forever.

Yay! Lets party!

XML is for data interchange, nothing else. Unfortunately, it's being used for everything but.

Re:Stuck (2, Insightful)

l0b0 (803611) | more than 7 years ago | (#16881500)

XML is for data interchange, nothing else.

Isn't all data interchanged? From client to server, from blogger to browser, from developer to developer, etc. Any data which is not interchanged is either useless or forgotten. And XML has shown its strength in all these areas: Ease of human and computer parsing.

Ho80 (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#16880066)

is mired in an However I don't probleim; a few playing so it's be on a wrong shout the loudest THINKING ABOUT IT. 40,000 coming gave the BSD their hand...she Channel, you might Distro is done Here obtain a copy of conversation and We all know, the party in street windows, SUN or than its Windows leaving the play Name on the jar of

Longevity (1)

scott_karana (841914) | more than 7 years ago | (#16880176)

What XML needs now is a standardized (even ad hoc) format for Binary XML. XML is such a verbose format...

Re:Longevity (1)

HeroreV (869368) | more than 7 years ago | (#16880484)

Then get to evangelizing. Fast Infoset [wikipedia.org] is ready to go.

Re:Longevity (1)

jibjibjib (889679) | more than 7 years ago | (#16881586)

WBXML perhaps?

just plain wrong (1)

mccoma (64578) | more than 7 years ago | (#16880282)

Apple replacing the perfectly fine, hand editable plist format with an XML version. ick.

a decade of ... (2, Insightful)

The Pim (140414) | more than 7 years ago | (#16880358)

vague semantics, confusing specifications, unwarranted complexity, standards proliferation, poor tools, and wildly inappropriate application. Not to mention rampant disregard for existing work in nearly every arena it entered. So the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. [bell-labs.com]

Re:a decade of ... (1)

operagost (62405) | more than 7 years ago | (#16880416)

If a standard is used inappropriately, it's not a flaw in the the standard. It's a flaw in the PHBs we allow to make uninformed decisions.

Re:a decade of ... (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16880816)

If you'd rather use SGML be my guest. XML solves the problem of beeing a simple to use subset of SGML very well.

Re:a decade of ... (1)

jibjibjib (889679) | more than 7 years ago | (#16881600)

XML and all the stuff that goes with it (DTD, XSLT, XPath, ) could hardly be described as "simple". There's a lot of stuff to learn if you want to be using XML as effectively as possible.

Re:a decade of ... (1)

thechronic (892545) | more than 7 years ago | (#16880892)

My understanding is that there isn't much to the standard, it's up to the application (such as SOAP) to define the "semantics". It's just a nice way to store and verify metadata.

When does a buzz word unbuzz (0, Troll)

cnlohfin3109 (758597) | more than 7 years ago | (#16881156)

Does this mean XML is no longer a buzz word? or is it still a way for self-important elitist 30 year old c programmers to feel superior by placing everything not used by them into a box so they can avoid change? does this make me a troll? I guess after 5 hours of applying the pumping lemma on theory of comp homework left me grumpy.

XML -- The answer to a problem that didn't exist.. (-1, Troll)

FlyingGuy (989135) | more than 7 years ago | (#16881172)

XML is just a pathetic attempt to do what SQL already does quite nicely thank you very much

You cqn query an SQL server and get the schema, then its a simple query for the data. Its all wrapped up quite nicely and its very logical and it works. Why oh why do these people continue to dream up this hierarchical madness!

So lets see, whats easier. You need data, you go to the data source and you request the schema of what you are getting. It comes from a table, a view or a query, but its a schema with defined field names and types. Then you query for the data, it comes in nicely packaged records and there you have it!. Now lets do it the XML way. You request some data. Then you spend the next several billion CPU cycles traversing up and down a hierarchical tree, building tempory array's etc. ad nauseum to get the data all sorted out.

Using a markup language that was designed to describe the layout of a page for data transfer is just plain stupid. STOP trying to make a one size fits all, use what is the simplest method for each task. You want to do page markup, use SMGL and its derivitives, you want to move data, use SQL, thats what it was designed for! This keeps the bug count low, it keeps troublshooting simple, it removes data from layout, its just a right way to do things.

Re:XML -- The answer to a problem that didn't exis (1)

trezor (555230) | more than 7 years ago | (#16881760)

You are trolling, right? Your rant basically consists of few obvious misunderstandings or statements that are factually wrong.

Seems like a knee-jerk reaction from someone who doesn't understand what XML is and its intended purpose. Seeing the HTML remark was rather amusing though. Way to go to show your ignorance on the subject.

BTW: XML is not designed to or intended to be a SQL replacement. Only morons would think that, claim that or use it as such.

Obligatory link (1, Redundant)

frenchbedroom (936100) | more than 7 years ago | (#16881394)

To the Parable of the Languages [burningbird.net]

What about me, said C#. I look like Prince!

Bite me! said C.

(I did a quick scan of the replies for the link and didn't find it, so mod me redundant if need be)

I think this... (1)

tonicblue (764384) | more than 7 years ago | (#16881496)

...would have been a more appropriate exert:

As they puzzled and wondered, the bushes at the end parted and XML walked into the light.
XML! Exclaimed C++. What are you doing here? You're not a programming language.
Tell that to the people who use me, said XML.

notice too late (1)

Tribbin (565963) | more than 7 years ago | (#16881574)

Celebrate the XML Decade:

Bah, it's too late to tell us to celebrate during the decade of XML because that decade is now over!

Yeah, should have done that; celebrating.

Significant technical victory (1)

gborland (602893) | more than 7 years ago | (#16881878)

XML has won a significant technical victory. It has managed to stand firm in the face of the relentless onslaught of doubling processor speeds and memory capacities, so that our word processors are just as slow and bloated as they were a decade ago. Outstanding! Yay for XML!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>