- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Yuck. Fixed length files suck. I generally take mine and run 'em through a function that kills whitespace and puts the result into XML (which works great if you're not an anti-XML nazi like half the people here seem to be). Takes a goodly while to run if you have a lot of data, but it's not half as bad as having to do the reverse, which I do sometimes for an old "TurboImage/XL" flat database we've got running a legacy accounting application. Nothing like adding millions of spaces to a flat file, and then figuring out you forgot to pull the carriage returns or some similar stupid crap.
Admin
I think its a sexy reproduction of the Firefox logo.
Admin
I think I should scroll down the page a little next time.
Admin
Obligatory link to fuel the ANT/XML fire:
http://web.archive.org/web/20041027130834/www.x180.net/Journal/2004/03/31.html
Admin
Nice procyon, how much time would it take you to implement your PML (PIEMEL is a dirty word in Dutch) parser in
Then when you're done, start working on the nice XPath, the nice XSL, the nice schema validators, the nice SAX parsers for those times you don't want a grow a tree, and get every nice web site to implement RSS/Atom in PML. Also don't forget that every OS should have an editor that's able to deal with PML. Good luck.
<data>
<!-- See if you can spot the error in less than 10 seconds -->
<datum>end tags are stupid
</data>
I'm gonna let you off on the there being no such thing as a human readable text file format, I trust you were just being silly there.
Admin
<font size="5">W</font>ay off topic but--I, for one, do not find spherical breasts to be attractive, current Hollywood trends be dammed. What is the point of those obvious implants and augmentation surgery?
Admin
The problem si that most people misunderstand what XML is. XML is a file format plane and simple, with metadata about the format imbedded in the format.
Advantages: Human Readable, Usually Forward/Backward compatible, meta data embedded Disadvantages: very very Bloated
thats it period.... BOTH apps still have to understand the format. Sure if App A sends App B an XML file, and B doesn't understand it, it won't croak. Bbut if it doesn't understand it, B still can't do anything with the data.
XML is an interesting format, and works for somethings. But it is not the be all end all.
Admin
I'm stoked to see some fellow XML-haters in here. "procyon112" made some good points. But now to rant on some others.
XML is designed the way it was because it was based off of HTML. Yes, that's right **XML IS BASED OFF OF HTML**. Seriously, this whole buzzword/paradigm is based off of a crappy markup language. Hey everyone, let's build a house based off of a fisher-price tryicle.
It was designed to be "human readable" and read by a machine. The XML piece "<stupid>format</stupid>" has as much sematic meaning to a machine as "0F55 1A82 0051". And as far as machine readability, it sucks at that too. The entire stream must be read before you can use it.
While I'm ranting, has anyone ever actually paid attention to the graphic format SVG? When someone told me it was XML-based, I thought they were joking. How did anyone think this was a good idea?
Admin
I think SAX parsers report elements at the moment they're completed in the stream, at which point you can do whatever you need to, just like when you're reading raw text files.
And "<stupid>format</stupid>" is obviously better readable to humans than "0F55 1A82 0051". xmlsucks.com describes XML being optimized for 'neither machines or humans', which is just a negative way of saying, 'both human and machine can tolerate XML'.
As for SVG being XML based ... it's an interesting design decision, I wonder what they were thinking. At the very least, it's easy to read and write SVG files now. And it's also easy to convert SVG files to a proper binary format.
Admin
Actually there are plenty of streaming readers for XML. SAX implements an event based model, but if I need something quick and dirty I use regex.
You're completely correct that the "tag" metadata is not very machine readable. In my experience, there are two places where XML works out pretty well.
First, configuration files and the like. If a file only needs to be read and parsed once during startup, I don't care that it isn't lightning fast. I like that I can edit it pretty easily.
Second, moving around small amounts of data where performance isn't a huge factor. Again, I like that I can easily see complex data when I am troubleshooting. When the data is too large or the app is too performance sensitive, however, XML just adds way too much overhead. I've been asked to build apps around 800MB xml files, and it isn't pretty.
Admin
"XML is lisp with [devil's] horns" - Brian Foote
"XML is a giant step in no direction at all." - Erik Naggum
Nay sir, XML is a subset of SGML, the fact that HTML is an SGML dialect is completely irrelevant.
And if you want to get even older stuff, SGML is based on GML which, like, completely incredible: a GML tag starts with a colon and ends with a period.
You read it well, a SGML tag written <mytag attribute="attr"> would be written :mytag attribute=attr. in GML. And an ending tag (or an element) is the same as the starting tag except that you prepend "e" to the identifier.
Wondering if it'd look great? try along the lines of
Admin
Aliens was the greatest movie EVER.
As for XML: It's like rope. Some people do clever/useful things with it. Others hang themselves.
Thanks
Admin
Hmmm... let's analyze it:
Hentai-like drawing equals nerds;
Firefox equals nerds;
Coincidence? No.
Also:
OMGWTF she has fire coming from her arse!!!
Admin
Beggin' Colonel's pardon, but...
The girl in the picture has 3-inch toe and finger nails shaped like claws, a tail that looks like fire coming out her ass, abnormally-large eyes, what appears to be fur/feathers growing on her shoulders and fore-arms and she is larger than the planet Earth.
And you are complaining that her hooters are "globular"?
Thanks
Admin
We've already seen the same misuse of relational databases. Are the standards for relational databases broken then too? Furthermore, just because an XML document is well-formed or even valid doesn't mean that its not a misuse of the standard. I can write a perfectly valid C# program using the mostly ungodly, confusing, and hard to maintain design I can think of (you could probably find some good examples on this site). Better yet, I could make it a C++ program and write the whole thing using tons of obscure macros. It would be a 'valid' program, but would it be a misuse of those languages? You betcha. Don't blame the standard just because certain programmers follow the letter of the law (of the standard) and ignore the principles and intent for which the standard was made.
Admin
Nice rant! Too bad you don't know what you're talking about? masklinn is correct here. xml is NOT based on html whatsoever. If anything it's the INVERSE: XHTML is HTML, but reformulated in XML (and some other changes) - which IS a good thing!
As far as semantics go, most XML I've encountered was pretty good. You can only blame whoever wrote the implementations you've seen/worked with - just because you've seen stupid implementations doesn't make the format itself bad. Flexibility is a good thing - not knowing how to use a tool properly isn't.
Machine readability? It's quite good at that really. XML can be exchanged between platforms and can be used with just about any programming language rather easily. Like anything, there are good uses for it, and other scenarios where something else might work better. It's not meant as something for very long data streams (and perhaps the problem could be how your data is stored more than anything i.e. the data could be on an SQL Server which returns XML).
XML is GREAT for certain things, like config files, locally caching bits of DB data (which are reused and may be tmie consuming to get) and especially web services. Do you think web services should use something like CSV instead? Or proprietary binary formats with encoding and endian issues and such? XML works fine for this. It may not be perfect, but it's far better than what we had before for many tasks. It's a tool, and it has some good uses (but yes, there are other tools, and not everything is a nail).
Admin
And she has hair on her legs, arms and shoulders, she's secretly a dude
Admin
The funny thing about SVG is that it is meant to be human-readable, because it's written in XML.
Unfortunately, the pure complexity of a non-trivial vector drawing makes it difficult to read in any language. SVG is not the first "standardized human readable vector drawing format". PostScript is also human readable (kind of;-), standardized and can be used to describe vector drawings.
The convenient thing about XML is that parsers already exist on every plattform. In theory, all parsers behave identically. In practice, it's like Java: write once, test everywhere
Admin
Customer: "This crap is unacceptable!!!1 This is the 21st century, you must use XML for EVERYTHING!!!1"
Developer: "'kay... Do you have a DTD or a Schema in mind?"
Customer: "Don't get all technical on me! Just give me XML!!!1"
Developer: "..."
You see, XML itself doesn't solve anything. The customer shouldn't care what format this is in, unless he wants to process it somehow. If so, he should request a particular DTD (and not generic "XML") or at least describe his requirements more clearly. Obviously he didn't, and he got all he asked for in return.
Admin
If I can, I try to make my xml documents as simple as possible. I avoid using name spaces and the like unless I really need to. When I do this, I can rely on being pretty consistently parsable accross lots of platforms. Besides, simple documents are more readible.
I have two big arguments with Web Services as implemented today. 1) The WSDLs are too complex and have too many unneeded layers. A developer that doesn't use them every day has a hard time making heads or tails of it. 2) Architects choose to use Web Services for interchange of large volumes of data. It is no fun working with XML documents that are tens of MB, and the performance hit is large.
And my biggest rant, Web Services != SOA!
Admin
Well, I'm a little late in the conversation but I must say that we are putting the blame on the wrong people. This certainly is not the doing of Flat File Society. It's a joint project by the Batch File Consortium (BFC) and INI File Precursors Association (IFPA). The project's name is Widely Transmittable File Format (WTFF).
Admin
That's not only debatable but extremely debated, and as far as I made my mind i'd say "no it isn't a good thing", first crap that comes to mind being the stupidity of the XML "error handling". Yellow Screen of Death anyone? You don't know what it is? Wait till XHTML served as XML becomes common and you'll learn the pain fast enough.
I, for one, thank god for the IE team to decide not to include the application/xhtml+xml MIME type into Internet Explorer 7.
Admin
XML doesn't have "error handling". Its either well-formed XML, or it isn't. It is either valid according to a given schema/DTD or it isn't. This is all that the standards define. Its up to the programmer to decide what to do when they get invalid or malformed data. If a particular library/browser you're using doesn't handle such errors well, then thats the fault of the people who made that library/browser.
The worst decision they ever made with HTML and the development of browsers was to allow people to make malformed or invalid HTML documents and rendering them anyway. This means that, by definition, the document cannot be rendered in a standards-compliant manner, and the writer of the HTML usually has no idea he/she did anything wrong. This ensured that 99% of the pages on the Internet have at least some, if not lots, of HTML syntax violations. The only reason that we've been able to cope with this mess is through lots of trial and error, both on the part of the HTML writers and the browser writers, so that the pages will behave as expected on all browsers. XHTML is part of an effort to require that a document be syntactically correct. Yes, there will be a lot of pain in the process, but thats because its an attempt to clean up the mess that is HTML.
Having said that, I realize that HTML is a great and very flexible tool that, for better or worse, is greatly responsible for the Internet being what it is today. Still, it is lacking in a number of areas, and syntax enforcement is one of the big ones.
Admin
And that IS error handling, it's part of the specification: if not well formed, blow up. There is no error recovery, but there is error handling.
Fail, that's the very reason why HTML DOES work.
The web would NEVER have taken off if we had had to use XHTML. See, that's the "Be strict in what you produce, be lenient in what you accept" approach.
Now granted HTML could've been slightly better, with more defined error recovery modes, parsing error displays and such, but XML's way of doing it is stupid, because getting a big yellow page saying that there is an error in the XML document doesn't help anyone. The client just wants a page, doesn't help him cause he gets no page and no way to tell the author "hey you suck your pages don't even work", and the author doesn't get any error message (since the error itself is client-side) so he won't know about it and won't be able to fix it.
XML/XHTML's error handling is stupid because XML has no error recovery period.
Admin
Nothing in the XML specification told Mozilla what to do when it recieves a mal-formed XML document, or an invalid XHTML document (yes, there is a difference). It merely defines what it means to be well-formed XML. And the XHTML specification only defines what it means to be valid XHTML.
I understand the need for browsers to make a best effort to deal with a problem when it occures. But it shouldn't be so forgiving that it makes every possible effort to divine what the HTML author meant and not even warn the user (who might well be the author) that the HTML document isn't valid! Perhaps, instead of a "yellow screen of death", Mozilla should display an error icon (like many browsers do with scripting errors) when it gets bad XHTML and then revert to treating it as HTML so it can at least attempt to render it. XML defines when an error has occured, not what to do about it.
Frankly, the only reason you're getting bad XHTML is because the browser the developer used rendered it the way the author expected it to, so the developer wrongly assumed his/her XHTML was correct. If the browser he was using had told him "HEY, FIX YOU'RE PAGE BECAUSE THIS PAGE IS JUNK!", the developer would have already fixed the problem.
Compilers don't let you run programs that are riddled with syntax errors. The same approach should have been taken with HTML a long time ago. On one particular occasion I was asked to make changes to a website produced by a very pricey vendor, only to find the site full of HTML that is riddled with glaring syntax errors (like table structures embedded 5 levels deep that have no closing tags) and yet can still be rendered by some browsers (how I cannot fathom). Of course, the changes I tried to make caused the pages to render in unpredictable ways. So, instead of focusing on the new features they wanted implemented, I spent my time cleaning up the other vendor's HTML. The vendor would never have been able to get away with this if they had been required to conform to HTML syntax. Instead, the browsers were so forgiving that no one knew they were wrong until it came time to make changes to it.
Admin
Maybe you should read a bit about XML's history and the fact that XML DOES require a "fail on first error" behavior and disallows any kind of error recovery. See here for more
A browser is, at it's core, a SGML parser. SGML parsers cut a lot of slack to the user and have a hell of an error recovery ability.
...
And the web as a whole would be dead by now.
Admin
It's called third-normal, look it up. Relational databases have additional strict standards to which you can hold the usage up to, XML lacks these. We mock bad databases not for their use of a database, but for their inabillity to adhear to the standards of proper database design. It doesn't take a rocket scientist and most times the data is organized into a flatfile using the same rigid rules and THEN tossed into a single row table. We mock going to all that effort and then wasting it.
XML however, has no future such standards.
Admin
The image and what it says about you is disturbing on so many levels.
Admin
Doesn't take much to disturb you sir, you should try to visit 4chan /b/ on Furry Friday, you'll see what "disturbing" really means.
(Note: you can see disturbing things every day on /b/, but Furry Friday is special).
Admin
Damn! That is some LOOOONG butt-hair :P
I don't date girls this hairy though....
Admin
<path d="M100,200 C100,100 250,100 250,200 S400,300 400,200" /> looks pretty much as if designed by the flat-file society :-)
Admin
Wondering if it'd look great? try along the lines of
Wow, somebody else remembers GML. It's far from WYSIWYG but it was a darned rich markup language. IBM used their mainframe SCRIPT programrsion to produce all their manuals for many years - and so did I. Building up large documents out of many files, fine control over table of contents and index entries were a few of my favorite areas.Admin
Yep, it should allow for an anonymous end-tag, "</>", which ends the last opening tag.
That would be a start.
Admin
... you won't see any data because the XML tags indent them beyond your window, or because the 26 % of actual data look exactly like the 74 % of XML tags.
Admin
Are IDs or types consistant between different files in the same data format?
How do you make sure two people/companies don't use the same ID?
What if you receive files from two different companies that happen to both use the same ID for different things. How can u easily merge the two files without having to redefine two new ID numbers?
If you are going to make a binary file format, at least have the balls to include a summary lookup table at the start and possible indexes for fast finding. And add the support for 'null' space that allows additional tags or elements to be inserted into the file without having to rewrite the file.
The null space is optional, but if u know someone very likely will later want to add a value to a tag, you can tweak your application to insert some null space in advance.
d
Admin
@Procyon: yeah, it would kick XML's ass. Until you'd perhaps like to stream it because your data structure doesn't all fit in memory. Or until you have to handle a substructure that's too stupidly big to fit in 4GB. Or until you have data corruption and need some redundany in the format to recover as much as possible.
XML doesn't have these problems. It has different problems, I'm not denying that.
NB: Tag names in utf-16? Given that they're going to be mostly ASCII, I fail to see what advantage that would have over plain simple utf-8.
Admin
You have to understand that those anti-xml nazi are oftentimes lacking in more than rudimentary skills in programming using Xml. In fact, I would venture to say that those who rant against Xml are also mediocre programmers because if you were good, you'd know the worth and limits of xml and use xml where it is judicious, like anything in the programming world.
Xml caught the imagination of software architects and middle to senior developers for what it can do to overcome today's problems. Average and below-average programmmers whose radar screen did not include how Xml could solve problems encountered in the Enterprise were for the most part unconvinced of its merits, and for the other part, felt threatened because this became yet again another technology that they had to learn or lose out.
The moment anyone opens his mouth and says Xml should be consigned to oblivion without providing at the very least some architectural reasons for it is a very scared and angry programmer whose skills do not include a proper depth, appreciation and understanding of the prevailing problem domains in the Enterprise space.
In short, they are plain dumb.
Admin
Geeeze, either there are a bunch of puritans reading this forum, or you're all imagining hentai-ish action with the fox-lady there ...
By the way, I was referring to the image's concept...
Foxes (kitsune) are sacred to Japanese, and this pic is a mix of elements
Firefox+Sacred+Manga
Admin
Or maybe they're plain annoyed of the sheer abuse of that thing, with 95% of the current usages of XML being stupid and bloating.
Try to take your little paragraph, s/xml/vb/, you'll get exactly the same thing, that is to say: void.
No, XML mostly became a buzzword (just what Ajax is currently becoming fyi) and therefore a "must-have" for any corporate pointy-head.
Admin
You must have come only recently into the I.T. Field. Xml was catching on well in 1999 and 2000 way before AJAX was ever coined, although its practices were being developed and coded in web applications in ASP !! ASP+XML gave extended life to a limited platform whilst waiting for the .NET Framework to take shape.
Before AJAX was even a term, a number of programmers in the Xml space were the celebrated XmlHttp object from Microsoft's parser to emulate a client-server environment with postbacks occurring discreetly instead of explicitly. And this was in 1999/2000.
As for the abuse of XML, it is too sweeping a statement to say that 95% of current usages of Xml being stupid and bloating.
Admin
May I ask what the flying hell led you to say such an obvious thing? Where the fuck did I state that XML was a recent buzzword and was born thanks to ajax?
Admin
+ woman needs to shave her legs
Admin
XML was developed by manufacturerers of 300 Gb Disk drives.
</truth>
Admin
The real WTF is all the people quoting that damned Foxy image every time they want to add a pithy remark. [pi]
Admin
I personally think XML is for idiots BECAUSE of this "total human readability" thing.
ht's a brain-virus from those wannabe-coders called "web-developers".
I thing IF you want a portable flexible format simply use EBML and create a reference explaining the tags in it. Then you got a 100% portable extensibe AND small interface. You even could make it human-readabe if you took a converter to xml or an editor who both would use a file associating the tag-ids to strings like in the reference.
Actually i'm developing a client-server multi-user life-management-system using this ideas right now.
Admin
People hate XML because it isn't a rigorous standard, but they haven't heard of any of the higher-level standards that are implemented in XML. People hate XML because the entire stream has be read before they can do anything with it, but they've never heard of SAX. People hate XML because they don't like implementing schemas as DTDs, but they've never heard of XSD. People think XML is ridiculous because it's "BASED OFF OF HTML", but they've apparently never heard of SGML.
The WTF here is that people are shooting their mouths off about technologies they clearly don't understand.
XML, in and of itself, is a simply, loose, generic, open standard that other standards can be implemented upon. Yeah, if you're Billy Joe Bob implementing BJBML, you're not going to get much benefit in the way of interop, granted. But if you're the W3C, or a coalition of companies involving, say, IBM or Adobe, it makes a lot of sense to base your standard on XML. You get an established syntax, which means you already a bunch of parsers, validators, apis, editors, and more to deal with your data. And, because of all that, converting data into or out of your format from other XML-based formats is relatively simple. Hell, even if you are Billy Joe Bob, you still get all those advantages with your format -- you just don't get the audience, unless your standard is pretty good and catches on.
This is why something like SVG is cool even though OMFG IT'S TEH XML!!! You can pull data from somewhere in XML, run it through XSL to merge it with SVG you've written, and dynamically generate complex graphics, animations, or UIs. That can be extended even further if you're using those graphics within, say, a DocBook or DITA project. Your data is cleanly separated from your business and presentation logic, you only need a small toolset, all of it open-source, with a consistent underlying syntax, and it will work on almost every platform you can imagine. And you can even process it in a SAX event pipeline.
Of course, it's not perfect. Like any other technology, it has its limitations and there are plenty of ways to abuse it. In particular, it's not great for encapsulating a lot of binary data, and it can sometimes be overkill if you're working with a pretty flat data structure that's not going to be used outside of your application (for example, a java properties file.) And, like in today's example, it's completely pointless if you're just going to embed giant CDATA blocks in it.
As far as the syntax, yeah, it's wordy. I'd imagine that most programmers here can appreciate the value in being able to edit XML as plaintext, and that wordiness can be useful in keeping things straight for the degree of nesting that can happen when you're trying to model even moderately complex data in a tree structure. If you don't like that, though, there are plenty of editors out there that will streamline things for you. And yeah, XML isn't lean, but if all we wanted was lean we'd be writing everything in assembler. Portability costs, deal with it. Storage space is cheap, memory is cheap, processors are cheap, bandwidth is getting pretty cheap. Parsing, storing, and transmitting XML are generally pretty painless here in the 21st century, unless you're dealing with truly massive amounts of data, in which case you should be using an XML store to deal with all the pain for you.
Admin
Not to mention the fact that XML, being text based and all, compresses VERY well. If you want to save space or bandwidth, all you need to do it zip the XML stream (assuming you're using a protocol that allows this).
Admin
You guys are WAY off. Thats not fire and she's certainly not a dude. Her problem is that she needs to trim that bush. BY hey, at least the <FONT style="BACKGROUND-COLOR: #ffa500">carpet</FONT> matches the <FONT style="BACKGROUND-COLOR: #ffa500">drapes</FONT>.
Admin
Admin
To clear things up a bit:
No one forced them to use XML, they said 'Oh yeah, we can handle XML - just send us your XML data!'.
No only that there is logic in there, they process my XML using absolute positions! So when I decide to add a tag, their code will break.