Slashdot Mirror
The Future of XML
An anonymous reader writes "How will you use XML in years to come? The wheels of progress turn slowly, but turn they do. The outline of XML's future is becoming clear. The exact timeline is a tad uncertain, but where XML is going isn't. XML's future lies with the Web, and more specifically with Web publishing. 'Word processors, spreadsheets, games, diagramming tools, and more are all migrating into the browser. This trend will only accelerate in the coming year as local storage in Web browsers makes it increasingly possible to work offline. But XML is still firmly grounded in Web 1.0 publishing, and that's still very important.'"
Sparingly. JSON is just plain better, and doesn't inflict an enterprisey mindset on anyone that tries to use it.
XML is like violence. If it doesn't solve your problem, you're not using enough of it.
I don't get it. We can argue the merits of data exchange formats 'till we're blue in the face; yet I cannot see why XML is so popular. For the majority of applications that use it, it's overboard. Yes, it's easier on the eye, but ultimately how often do you have to play with the XML your CAD software uses?
I'm a programmer, just like the rest of you here, so I'm quite used to having to write a parser here or there, or fixing an issue or two in an ant script. The thing that puzzles me, is why it's used so much on the web. XML is bulky, and when designed badly it can be far too complex; this all adds to bandwidth and processing on the client (think AJAX), so I'm not seeing why anyone would want to use it. Formats like JSON are just as usable, and not to mention more lightweight. Where's the gain?
ilovegeorgebush
It seems to me to be a slight improvement on ini files, csv and the like. But parsing it is hideously inefficient compared to a binary format. It's bloated too, so it takes more time to send it over the net or save it to disk. I've seen some XML schema that are aggressively hard to read too. And yet it's become something that every new technology, protocol or applications needs to namecheck.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Nope... never ever have heard that one before....
XML is like violence. If it doesn't solve the problem, use more.
Rule #6 - If violence wasn't your last resort, you failed to resort to enough of it.
http://www.schlockmercenary.com/d/20050313.html
Netscape's dream of replacing the operating system with a browser is also coming true this year.
They've been saying that for years, and frankly it won't happen. A vast amount of users relish the control that having software stored and run locally provides. Of course there will always be exceptions as web based e-mail has shown us.
As far as the future of XML... I can't seem to find anything in this article that states anything more than the obvious, it's on the same path it's been on for quite some time.
FTA:
Success or failure, XML was intended for publishing: books, manuals, and--most important--Web pages.
Is that news to anyone? My understanding of XML is that it's intended use is to provide information, about the information.
I'm sick of following my dreams. I'm just going to ask where they're goin' and hook up with 'em later.
The think with XML is that it so easily supports whatever design the developer can think of. Even the realy bad ones. Now that it is such a buzz word, the problem gets worse.
I had someone call me up to design them a simple web app. But he wanted it coded in XML because he thought that was the technology he wanted. His Access database was not web frendly enough.
I did correct him a little to put him in check and atleast gave him the right buzz words to use to the next guy.
I think XML is dead simple to use if used correctly. I do like it much better that ini files. That is about all I use it for now. Easy to use config files that others have to use.
Im a gamer, not a grammer major. This post is full of spelling and grammer mistakes.
Don't click the "NIMP project" link. GNAA. Bad news. You know the rest.
I have had far too many 'this stuff sucks' moments with XML to ever consider using it in any capacity where it is not forced upon me (which unfortunately, it is, with great frequency).
I first heard about XML years ago when it was new, and just the concept sucked to me. A markup language based on the ugly and unwieldy syntax of SGML (from which HTML derives)? We don't need more SGML-alikes, we need fewer, was my thought. This stuff sucks.
Then a while later I actually had to use XML. I read up on its design and features and thought, OK well at least the cool bit is that it has DTDs to describe the specifics of a domain of XML. But then I found out that DTDs are incomplete to the extreme, unable to properly specify large parts of what one should be able to specify with it. And on top of that, DTDs don't even use XML syntax - what the hell? This stuff sucks.
I then found that there were several competing specifications for XML-based replacements for the DTD syntax, and none were well-accepted enough to be considered the standard. So I realized that there was going to be no way to avoid fragmentation and incompatibility in XML schemas. This stuff sucks.
I spent some time reading through supposedly 'human readable' XML documents, and writing some. Both reading and writing XML is incredibly nonsuccinct, error-prone, and time consuming. This stuff sucks.
Finally I had to write some code to read in XML documents and operate on them. I searched around for freely available software libraries that would take care of parsing the XML documents for me. I had to read up on the 'SAX' and 'DOM' models of XML parsing. Both are ridiculously primitive and difficult to work with. This stuff sucks.
Of course I found the most widely distributed, and probably widely used, free XML parser (using the SAX style), expat. It is not re-entrant, because XML syntax is so ridiculously and overly complex that people don't even bother to write re-entrant parsers for it. So you have to dedicate a thread to keeping the stack state for the parser, or read the whole document in one big buffer and pass it to the parser. XML is so unwieldy and stupid that even the best freely available implementations of parsers are lame. This stuff sucks.
Then I got bitten by numerous bugs that occurred because XML has such weak syntax; you can't easily limit the size of elements in a document, for example, either in the DTD (or XML schema replacement) or expat. You just gotta accept that the parser could blow up your program if someone feeds it bad data, because the parser writers couldn't be bothered to put any kind of controls in on this, probably because they were 'thinking XML style', which basically means, not thinking much at all. This stuff sucks.
Finally, my application had poor performance because XML is so slow and bloated to read in as a wire protocol. This stuff sucks.
XML sucks in so many different ways, it's amazing. In fact I cannot think of a single thing that XML does well, or a single aspect of it that couldn't have been better planned from the beginning. I blame the creators of XML, who obviously didn't really have much of a clue.
In summary - XML sucks, and I refuse to use it, and actively fight against it every opportunity I get.
The future of XML?
Probably a long, healthy life in a big house on the top of buzzword hill, funded by many glowing articles in magazines like InformationWeek and CIO, and 'research papers' by Gartner. Sitting on the porch yelling, "Get off my lawn!" to upstarts like SOA, AJAX, and VOIP. Hanging out watching tube with cousin HTML and poor cousin SGML. Trying to keep JSON and YAML from breaking in and swiping his stuff. Then fading into that same retirement community that housed such oldsters as EDI, VMS, SNA, CICS, RISC, etc.
XML is easy to understand because of the prevalence of HTML knowledge. XML is easy because it's text. XML is easy because, like perl, you can store the same thing in 15 ways. XML is easy because there is only one data type: text. XML is flexible because you can nest to your heart's content.
/. steps down yet another notch. IMHO: if you loathe/hate XML then you should think about a change in career because it's not going away any time soon...
All these things are why people use it.
All these things are why people abuse it.
All these things are why we won't be able to get rid of it soon.
TFA has nothing to say about the future of XML but the tools to use XML. XQuery and XML databases. Whoopity do. The threshold for getting posted on
:wq
JSON is lightweight, and yet it remains human readable and editable. XML lets you forget some of the security concerns of JSON, and has the advantage of not being tied to a specific programming language.
If only there was a standardized format that combined these advantages, without all that XML bloat. There is! Try YAML.
XML's big win is supposed to be its semantics: it tells you not only what data you have, but what sort of data it is. This allows you to create all sorts of dreamy scenarios about computers being able to understand each other and act super intelligently. In reality, it leads to massively bloated XML specifications and protracted fights over what's the best way to describe one's data, but not to any of the magic.
As my all time favorite Slashdot sig said: "XML is like violence: if it doesn't solve your problem, you aren't using enough of it."
XML is something that programs can use to do stuff for themselves, like writing and reading their config files, or a game or an MP3 player or, god forbid, a spreadsheet encoding its UI layout in XML so that any end user can come along and play with it.
What XML is not, and never will be, is a standard way for different programs written by different people to pass data around for an extended amount of time. It's a nice theory, but the key ingredient that would make it work in the long run will always be missing: People would have to settle on something and then stop screwing with it. That's never going to happen. Programmers and companies are constantly reinventing data structures and programs because they either a) get bored, or b) want more money. When either a) or b) happen, you get a new programming language or a new version of an operating system or a new whatever, and it's not compatible with the stuff that came before, now matter how much imcompatibility tolerance you attempt to design into something.
Before XML fanboys start squeaking that XML will solve all of that, I'll just say no, XML won't solve any of that, no more than Object Oriented Programming guaranteed that we'd never have to write another string class again. I've heard it all before. What each new generation will keep doing is throwing away investments and frittering away their lives relearning and reinventing ways to execute instructions on processors.
Doesn't that mean I can use it until um... er... text runs out?
It's not rocket science - MS were using it in MediaPlayer long before EkksEmmEll came along... it was called "sticking your crap in angle brackets and parsing it" - HTML is a subset of SGML and I'm pretty sure that it (in its XHTML form) will be around for a while yet.
How does that die out? Just because you give it a name and rant about standards in some poxy white paper/media blag doesn't mean it's going to die and go away...
Would you blame JSON for that or is it simply a case of selecting the right format for the job?
ok true story.
We once had to port live data from Texas to Oregon from giant tables repeatedly, not too well built. So we looked to send XML, enforcing a DTD/schema on the sender teams. We ended up writing the encoders because we used an early and crude compression scheme:
We took the source table and counted the number of duplicate sets per column, then returned sorted data in order of highest duplicates to lowest.
Then, we encoded in XML using a column, then row order. Scanning downward, if rows duplicated > 2x, we merely attributed the R tag with repeats="xx"
Additionally, if the sender detected non-duplicate columnar data, but could find repeating sets, there were more attributes for that.
This could be expanded into sequences, dictionary schemes, etc. This was 1998 and all the world was XML. I'm glad this concept died with web services, bandwidth, etc.
Essentially, the transfer of all this data as XML was interesting and fast(er) but didn't sacrifice the universality of being able to generate ascii-based text files from multiple (and divergent) sources. I came to see how XML could in fact be an OK choice for some communication formats.
Overall, it was a pleasant experience - but I've had too many others where folks wanted to shove XML into serialized objects for some strange reason (with no need for communication or human-readability).
While helping maintain work on an old game's source code, the thorny problem of which data storage format to use propped up, to replace the inflexible one in use with fixed references. There's two main developers, one who wants XML for flexibility, the other a binary format for speed and size.
XML was the main choice, but maintaining the files is trickier than it appears. It's one of the least "human readable" formats I've seen, much more so than HTML, where you know what each tag intrinsically means. This irks the second developer, who would otherwise have accepted a compromise, and there's a stalemate on the issue.
We have skipped around the issue and instead started work on adding other features and bugfixes. The only implementation which I did notice could work was SweetXML, though the time required to set this up wouldn't be as quick.
XML, and it's derivatives such as XAML, need to be easier to read and edit before they can become fully fledged on the web.
In the long run, we are all dead. XML's future is in the graveyard. Alas, that is probably too much to ask. :(
The only reason why XML caught on is because it looks like HTML. And since all the phony IT execs who have "HTML" on their resume were able to say they understood it.
S-expressions (think the lisp format) are much nicer, more compact, and easier to use than XML, while sharing almost all of the same properties otherwise.
For example:
<tag1>
<tag2>
<tag3/>
</tag2>
<tag1>
becomes:
(tag1
(tag2
(tag3)
)
)
If I have nothing to hide, don't search me
XML has tremendous, huge, giant levels of adoption that dwarf its use as XHTML and in XMLHTTPRequest (AJAX) stuff.
WHATWG's HTML 5 and JSON will have no effect on these other uses. It's just that nobody in hangouts like this sees it.
For example, the entire international banking industry runs on XML Schemas. Here's one such standard: IFX. Look at a few links: http://www.csc.com/industries/banking/news/11490.shtml , http://www.ifxforum.org/home , http://www.ifxforum.org/home
But there are other XML standards in use in banking.
The petroleum industry is a heavy user of XML. Example: Well Information Transfer Standard Markup Language WITSML (http://www.knowsys.com/ and others).
The list goes on and on, literally, in major, world-wide industry after industry. XML has become like SQL -- it was new, it still has plenty of stuff going on and smart people are working on it, but a new generation of programmers has graduated from high school, and reacts against it. But it's pure folly to think it's going to go away in favor of JSON or tag soup markup.
So yes, suceess in Facebook applications can make a few grad students drop out of school to market their "stuff," and Google can throw spitballs at Microsoft with a free spreadsheet written in Javascript, but when you right down to it, do you really think the banking industry, the petroleum industry, and countless others are going to roll over tomorrow and start hacking JSON?
Ok. I've once again seen the full range of XML comments here. From 'cool super technology modern java' to 'OMFG it sucks' right over to 'XML has bad security' - I mean ... WTF? XML is a Data Format Standard. It has about as much to do with IT security as the color of your keyboard.
And for those of you out there who haven't yet noticed: XML sucks because data structure serialisation sucks. It allways will. You can't cut open, unravel and string out an n-dimensional net of relations into a 1-dimensional string of bits and bytes without it sucking in one way or the other. It's a, if not THE classic hard problem in IT. Get over it. It's with XML that we've finally agreed upon in which way it's supposed to suck. Halle-flippin'-luja! XML is the unified successor to the late sixties way of badly delimited literals, indifference between variables and values and flatfile constructs of obscure standards nobody wants. And which are so arcane by todays standards that they are beyond useless (Check out AICC if you don't know what I mean). Crappy PLs and config schemas from the dawn of computing.
That's all there is to XML: a universal n-to-1 serialisation standard. Nothing more and nothing less. Calm down.
And as for the headline: Of-f*cking-course it's here to stay. What do you want to change about it (much less 'enhance'). Do you want to start color-coding your data? Talking about the future of XML is allmost like talking about the future of the wheel ("Scientist ask: Will it ever get any rounder?"). Give me a break. I'm glad we got it and I'm actually - for once - gratefull to the academic IT community doing something usefull and pushing it. It's universal, can be handled by any class and style of data processing and when things get rough it's even human readable. What more do you want?
Now if only someone could come up with a replacement for SQL and enforce universal utf-8 everywhere we could finally leave the 1960s behind us and shed the last pieces of vintage computing we have to deal with on a daily basis. Thats what discussions like these should actually be about.
We suffer more in our imagination than in reality. - Seneca
If I use XML, I can embed documents in other documents of different types, and they share a DOM. I can serve an XHTML document with MathML and SVG inside it, and use one CSS file to style everything, and my Javascript file can play with all of the above.
JSON is neat, and it's great for some things, but I haven't seen anything from the JSON people that even approaches what I can do with XML in a browser.
http://talkback.zdnet.com/5206-10533-0.html?forumID=1&threadID=44087
He killed his laptop and couldn't use his desktop for a couple of hours.
Put identity in the browser.
Cheers, Qbertino. This is the best explanation of XML's raison d'etre I have ever heard.
I think what people might hate most is DTDs. That makes sense. Even their creator says they suck. There are many ways around them... Lisp can be one big full-service XML processor. Easily. With happy ending and no need for the DOM or SAX.
The bottom line is, XML is nothing (literally) until you spec YourML. And most people don't have a need for that! So it seems useless to them. If you are writing markup languages for application spaces that don't have them it's a godsend. And it is leading to improvements and much-needed standardization.
I've never understood why seemingly rational people whine about XML. It's like whining about mathematics. They're like that for a reason; their intrinsic structure provides their utility. It's not some arbitrary syntax decision that you can whine about. Don't like how modulo works or the concept of recursion? It's AXIOMATIC, baby. Don't like close tags? They're there for a reason.
As for a SQL replacement... have you checked out Berkeley DB XML? Have you found anything promising that you like?
Use it if mandated, try to avoid using it for application configuration if possible, try to avoid transformations as much as possible, accept that web services / ajax do make sense in certain situations.
Basically like any tool use where it makes most sense, avoid using it in other cases.
You can't handle the truth.
XML tries to make everything fit into a single hierarchy. Most real-world information is comprised of graphs of data. ISO STEP provides better readability compared to XML, a more strongly typed schema mechanism, and a more compact size. Best of all, programs can process and present results of STEP incrementally instead of requiring closing tags so you can hold gigabytes of information in the same file and seek randomly.
Example:
#10=ORGANIZATION('O0001','LKSoft','company');
#11=PRODUCT_DEFINITION_CONTEXT('part definition',#12,'manufacturing');
#12=APPLICATION_CONTEXT('mechanical design');
#13=APPLICATION_PROTOCOL_DEFINITION('','automotive_design',2003,#12);
#14=PRODUCT_DEFINITION('0',$,#15,#11);
#15=PRODUCT_DEFINITION_FORMATION('1',$,#16);
#16=PRODUCT('A0001','Test Part 1','',(#18));
#17=PRODUCT_RELATED_PRODUCT_CATEGORY('part',$,(#16));
#18=PRODUCT_CONTEXT('',#12,'');
#19=APPLIED_ORGANIZATION_ASSIGNMENT(#10,#20,(#16));
#20=ORGANIZATION_ROLE('id owner');
JSON and such is a bandaid since it's all about streaming today, why? because NVP nomenclature is easier than XML and the technology is slow. Why is the technology slow?, cause we're send the same stuff all over the place--inefficient web pages rule!
XML is to the semantic web where as JSON/YAML/etc.. is to Google. Guess what? The semantic web is finally catching on with real accurate results where as Google results are now more confusing...
Twice.
Dump the entire memory contents, and you probably store data you don't care about, being even more wasteful of resources than XML. If it was so painless, why would every modern framework explicitly deal with special calls to serialize objects? What if you dump the memory space of some object on an x86 and try to restore it on a ppc, which differs in endianness? What if you try to load it on a system with different data type sizes and the alignments mess up? What if you update your program to add a member to a struct, and suddenly you've corrupted the meaning of your binary save data from previous iterations?
I'm not saying XML is the best answer or by simply saying 'XML' problems go away, you always have to do something and many different frameworks/facilities in various languages exist to help. You have to do something more than open a file handle and start dumping from memory addresses to that file handle. You have to either think carefully or choose a tool that let's you be fairly straightforward and preserve your options going forward.
XML is like violence. If it doesn't solve the problem, use more.
XML does suck if you stick with some of the W3C standards and common tools. Suggestions to make it less painful:
W3C Schema is painful; it forces object-oriented design concepts onto a hierarchical data model. Consider RELAX NG (an Oasis-approved standard) instead; it's delightful in comparison. Use the verbose XML syntax when communicating with the less technical - if you've seen XML before, it's pretty easy to comprehend:
Switch to the compact syntax when you're among geeks:
There's validation support on major platforms, and even a tool (Trang) to convert between verbose/compact formats, and output to DTD and W3C Schemas. And, if you need to specify data types, it borrows the one technology W3C Schema got right: the Datatypes library.
The W3C DOM attempts to be a universal API, which means it must conform to the lowest common denominator in the programming languages it targets. Consider the NodeList interface:
While similar to the native list/collection/array interfaces most languages provide, it's not an exact match. So, DOM implementers create an object that doesn't work quite like any other collection on the platform. In Java, this means writing:
Instead of:
Dynamic languages allow an even more concise syntax. Consider this Ruby builder code to build a trivial XML document:
I thought about writing the W3C DOM equivalent of the above, but I'm not feeling masochistic tonight. Sorry.
The alternatives depend on your programming language, but plenty of choices exist for DOM-style traversal/manipulation.
In-memory object models of large XML document can consume a lot of resources, but often, you only need part of the data. Consider using an XMLPull or StAX parser instead. Pull means you control the document traversal, only descending into (and fully parsing) sections of the XML that are of interest. SAX based parsers have equivalent capabilities, but the programming model is uncomfortable for many developers.
Even better, some Pull processors are wicked fast, even when using them to construct a DOM. In Winter 2006, I benchmarked an XML-heavy application, and found WoodStox to be an order of magnitude faster at constructing thousands of small DOM4J documents
Scott Severtson
Senior Architect, Digital Measures
XML is so popular because business people don't understand it and think it can magically do a lot of things it can't, so they choose software that uses XML when it really doesn't matter.
I have a lot of experience consulting with various organizations - some Fortune 500, some nonprofit, some educational - about their software selection process. I've watched many times as a vendor gives a presentation to my employer or client talking about how wonderous it is that their software saves all its data in XML so you'll be able to openly interchange it with everything. The business people's eyes glaze over and a happy glow suffuses their face, as they imagine that that means that any software's data that's saved in XML can be magically opened and understood by any other software that uses XML. They don't get the idea that there's a specific schema involved and that your word processor won't be able to automatically make sense of data generated by your database just because there's XML involved.
When I talk to my client after the vendor presentation I invariably learn that they think that XML is a sort of universal translator. I've had to explain why it isn't to so many clients I finally just wrote a white paper on the subject so when it comes up again I can just print it out and hand it to them. If I don't, I find my clients will reliably choose to buy the software that uses XML instead of the software that best meets their needs.
Believe me, the vendors knew that their prospective customers would act this way, and did everything they could to play up the idea that XML is magically interchangeable with all software, sometimes to the point of telling outright lies about it.
JSON is almost exactly equivalent to LISP S-expressions. Unfortunately, JSON has major security problems due to a Javascript design error. In LISP, there's the "reader", which takes in a string, parses it, and generates a tree structure (or graph; there's a way to express cross-links), and just returns the data structure. Then lISP has "eval", which takes a data structure created by the reader and runs it.
Javascript combines both functions into one, called "eval", which takes a string, parses it, and runs it. Giant security hole. There are attempts to patch around this, but it's ugly.
XML, its related technologies, and its rivals were designed to add cost to the business of managing data and information. In order to profit, developers interpose themselves between the product (data processing) and the customer (businesses). They do this by creating ridiculous technologies, dumb languages, over-complex components, and on and on. A perfect data language, while not existing, would not provide a profit opportunity to developers. The fact that a common function of XML editors is to display the structure without angle brackets is good evidence that they aren't needed. Many XML editor developers have obviously found a market in presenting XML without the ridiculous braces and open/close tag pairs (twice the work, twice the profit). GIS for XML editor and what do you see in every image? The proof is obvious.
XML will be around forever because it leverages more synergy than other less impactfull data aggregation schemes.
XML gives a good way to both mark up documents and to store hierarchical data in a format that's at least not openly hostile to being read by human beings like most binary encodings. Marking the closing tags seemed somewhat redundant at first, but it lets you know if a document is well-formed sooner rather than later so that you don't get to the end and find out that there's exactly one too few closing parenthesis with absolutely no idea where the missing one should go. XML documents can be compressed reasonably well and there are plenty of tools to work with them in one form or another.
The hierarchical format of XML has proven quite versatile in describing everything from vector graphics to mathematical formulas to musical notation to financial statements and invoices. All it takes to adapt XML to a new application is a definition of the syntax using a standard format and a description of the semantics and then people can start using it.
XForms is one interesting application of XML that shows how it doesn't need to be entirely passive. It doesn't describe what the forms it creates look like but rather how they behave. So you can say that you want the user to pick one of three options in a list and send back an event to the server when they choose. This description could then be put in a web page to get a web form, displayed using OS widgets in a regular program, stuck in an email, displayed on a smartphone, made into part of a curses application or used to place some checkboxes on a printed form. The best part is that the server doesn't even need to know or care exactly how these forms are being displayed.
You can have extremely simple, toddler-complexity structures or hugely massive structures with multiple namespaces, etc, etc,
But what really rocks is the standards and tools FOR xml; XSD, XSLT, XPath, XQuery and so on.
Xml on it's own is nothing to write home about, it's the other XML standards that make it great.
throw new NoSignatureException();
Deleted
I've been working with XML ever since it first came out and the whole XML on the front-end is a fad that comes and goes periodically.
The pros of XML
Cons of XML
The pros and cons mean that the best place to use XML is for interoperability between systems/applications developed by different teams/vendors where not much data is sent around and processing is not time sensitive. This does cover some front-end applications where the data can be generated by a program done by one vendor and read by a program done by a different vendor. It does, however, not cover files which are meant to be written and read by the same application.
The second best place is to quickly add support for a tree structured storage format for data to an application (for example, for a config file), since you can just pick-up one of the XML libraries out there and half your file format problems will be solved (you still have to figure out and develop the "what to put in there" and "where to put it" part, but need not worry about most of the mechanics of generating, parsing and validating the file)
using resolv.conf in it's current format
/etc files /etc file
converting to XML
?
Some people really like the idea of using XML instead of the variable formats of the configuration files. But they've never said WHY they want to do it.
Sometimes a file that says
a=3
is a lot simpler to work with than XMLing it and if you wanted to get the stated benefits (one tool will allow you to edit any config file) there's a shitload of work to
make a consistent schema for ALL your
make the help XMLised
make the validation sections
modify the programs that use the
and why? So we humans don't have to read the man page?
One thing that XML needs to have defined is non-fatal error handling: a larger and larger amount of content is dependant on non-fatal error handling (especially of Atom/RSS feeds), and also often on RFC3023 not being supported.
If non-fatal error handling is not specified soon, I fear that XML will fall into the same hell that HTML got into in the early 90s: everyone having to reverse engineer one-another to support content. Define it now, and chaos in the future can be avoided. Ignore the reality, and XML will fall into the same trap that HTML fell into. Idealism does not work. The world is not perfect.
YML... Or maybe even ZML.
- Tell the PHB's that the code you write will be human-comprehensible (suggesting maintanability), then create code with tags like <obfus:rangeScopingUpperOrLowerBoundDefiningIntermediateParameterIndex> so that only you (or someone with a few weeks to train in) can maintain your code
- Tell the PHB's that your code is interoperable while omitting the fact that it may take more logic to transform your XML so that it can "interoperate" than to generate it in the first place. More work for everyone!
- Perform the same type of magic as DBAs: "the information you want is in there, you just need to know how to get it out"
- More libraries = more bugs to work-around or fix
In spite of the above, I don't have an objection to XML as a data exchange format! It's particularly useful for wrapping data from a relational database.I also do not object to the use of XML in config files. Done right, it's a good idea. Spring's pretty good. The handy thing about XML config files is that by validating the XML document, you are also validating the data in it, to a certain extent.
I can think of cool things to do with things like Apache Digester and XSLT (things that might reduce volumes of code created. The "Spring" influence again
XML within a stand-alone application is useful for debug purposes (I'm thinking of the CAD example you gave): leaving it there smacks of laziness or time constraints
XML over the Internet is obscene. How many servers have to copy vast Strings around in order to transfer a few bytes from point a to point b?
Seriously, someone should attempt to calculate how much energy is required to transport all those pointless extra characters around. I don't have the knowledge (and have time constraints
I started to read TFA. The logo wasn't a good omen but there was a chance that the article would be useful because there are some brilliant people working there.
I scanned the introduction and no point leapt out at me. Once I found that the first section, "Oneiromancy" began with a cheap swipe at Sun, I quit. Not out of any loyalty to Sun but because I then knew that the document was likely to be merely propoganda and marketing-speak. In other words, more bloat...
Oh! You mean that thing that lacks unicode character support, that lacks any easy way to define the character set, and has plenty of other problems, like for example its inability to fail fast?
No, not fail-safe, I mean fail fast. As soon as an XML parser comes across a closing tag that fails to match the tag that opened it, the parser throws an parsing error. No so with S-expressions. With your LISP structural model, the parser/interpreter must find the closing parenthesis that fails to match. This means that it may parse to the end of a multi-kilobyte or multi-megabyte data file before it can ever know that anything is wrong? How is that more efficient?
(Answer: it's not.)
Then of course you would need to validate the input in the S-expressions. You *do* validate your input, right? Do you do it manually with LISP? How would you do it with any other language? After all, this solution of yours has to work with more than one programming language, right? For some reason, validating the input from an S-expression in C doesn't sound fun.
XML has DTDs (although I don't particularly like them), XML Schema, RelaxNG, RelaxNG compact syntax, etc. All of them work, and all of them have a strong following, so there's not much danger in choosing the "wrong one." Just use what you prefer. Well, of course, that is if you're using XML and not S-expressions. With S-expressions, you're just SOL.
So have fun in your own little S-expression world.
- I don't need to go outside, my CRT tan'll do me just fine.
<Sentence>
<Words>
<Word>I</Word>
<Word>don't</Word>
<Word>see</Word>
<Word>what</Word>
<Word>all</Word>
<Word>the</Word>
<Word>fuss</Word>
<Word>is</Word>
<Word>about</Word>
</Words>
</Sentence>
That was the turning point of my life--I went from negative zero to positive zero.
Because there is no such thing as a "superior" format. They all have their quirks. Engineering is about tradeoffs, not about religious contests...
-Stu
I've found that XML is great for Object persistence in Java. The library to use is XStream.
The closing of Harold's article proposes a basic data format for XML. In fact, that's exactly what XStream provides out-of-the-box.
I love XML because it makes things work easier. I wish that XML could be implemented in SQL or some other sort of database system or even mange XML as some sort of database. The thing is XML will always be a backend.
Networked computing means more communication of data among heterogenous systems. But XML is just one way to serialize data. Also, we should remember that data is often stored permanently somewhere, not merely transferred and forgetten in a chain of computers handling one transaction. There will continue to be multiple formats at the low level (XML, JSON and language/application specific forms and so on) for some time. If there is to be consolidation to fewer formats, there is no reason to doubt that XML could be squeezed out quite soon.
If we see JSON being used more in the browser, and hence in the webserver, then why should developers waste effort to convert it to and from XML? We could have entire applications using JSON for everything from the database storage to the browser.
Just because DTDs suck doesn't mean you can't use RelaxNG or XML Schema, both of which allow you to constrain the values allowed for text or an attribute. As for blowing up when an element name consists of 100MBs of 'a' *AND* you are validating that XML document against a schema, that's a bug in the parser you're using, and you should file a bug report.
- I don't need to go outside, my CRT tan'll do me just fine.
The following in RelaxNG compact syntax might be more palatable to some:
element myelement { xsd:token { minLength="1" maxLength="20" } }
Great post. I heartily enjoyed it. Cheers!
- I don't need to go outside, my CRT tan'll do me just fine.
everything looks like a nail.
That's the problem with XML. We have all these wonderful XML tools, so the solution to everything looks like XML.
I am sure XML has its uses.
Recently I interviewed for a job where they proposed a problem to me, asking how I might solve it. It was an issue of needing to track a lot user permissions for potentially thousands of users across hundreds groups of users; how do we add/remove a permission for a range of users? How do we set a default set of permissions and then override certain perms? etc. My answer was: store it in relational database tables. user, group, perm, group-perm-xref, user-perm-xref. I almost couldn't give an answer to their problem because I didn't understand why it was a problem. Yes, it would have ended up with millions of records. Big deal. MySql is fast.
You know what their solution was going to be? Just have a text field in the user record and put all the permissions in there as.. wait for it.. XML! Oh joy!
Needless to say I did not get the job. Which is fine since I got a job a week later where I work from home and when I suggest a method of doing something my co-workers actually listen. The topic of using XML for essentially a config file has been brought up and thanks to this thread I have some alternatives to consider (YAML).
--
Aric Caley,
Fonality, inc.
-- Senior Software Engineer, Attorney appearance services, locallawyerapp.com.