• (cs) in reply to BradC
    BradC:

    Sheesh. Looks like similar to a problem I'm dealing with at work. We have been parsing some fixed-width text files from a vendor that looked like:

    <font face="Courier New">Johnson   Dallas    TX    4291.3020051205
    </font><font face="Courier New"><font face="Courier New">Smith     Seattle   WA     900.0020051201
    </font><font face="Courier New">WashingtonNY        NY    1200.5020051215</font></font>

    Not too bad, but just for consistency with some of our other vendors we asked if they could send CSV file instead. Here is what we got:

    <font face="Courier New">"NAME, CITY, STATE, AMOUNT, DATE"
    </font><font face="Courier New">"""Johnson   "",""Dallas    "",""TX  "",""  4291.30"",""20051205"""
    </font><font face="Courier New"><font face="Courier New">"""Smith     "",""Seattle   "",""WA  "",""   900.00"",""20051201"""
    </font><font face="Courier New">"""Washington"",""NY        "",""NY  "",""  1200.50"",""20051215"""</font></font>

    <font face="Courier New"><font face="Times New Roman">We stuck with the original format :)</font></font>

    <font face="Courier New"><font face="Times New Roman">(Crossing my fingers that this post shows up correctly...)</font></font>



    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.

  • (cs) in reply to JohnO
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?



    I think its a sexy reproduction of the Firefox logo.
  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?



    I think its a sexy reproduction of the Firefox logo.


    I think I should scroll down the page a little next time.
  • Grant (unregistered)

    Obligatory link to fuel the ANT/XML fire:

    http://web.archive.org/web/20041027130834/www.x180.net/Journal/2004/03/31.html

  • (cs) in reply to procyon112

    Nice procyon, how much time would it take you to implement your PML (PIEMEL is a dirty word in Dutch) parser in

    • Perl
    • C
    • C++
    • .Net
    • COM
    • Java
    • Python
    • JavaScript (IE, Firefox, Konqueror, Safari, ....)
    • Ruby
    • VB
    • Tcl
    • ObjectPascal
    • PHP
    • is that a puddle of molten courage under your chair?

    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.

  • (cs) in reply to Rui
    Rui:
    masklinn:
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?

    Nope, it's a rendering of the "Firefox Lady" by Toybox

    [image]

    Link to Toybox' post if the image doesn't work

    I thought that this rendition was awesome (while his rendition of the Xbox 360 is much less artistic) and started using it pretty much everywhere (i'm also using it as my desktop image).



    Sorry about the double post, but I just have to say this:

    That image rules !

    <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?

  • Chris (unregistered) in reply to DiamondDave

    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.

  • (cs) in reply to procyon112

    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?

  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:
    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.


    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.
  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    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?



    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.
  • (cs) in reply to boa13
    Anonymous:
    DiamondDave:
    So, why do people keep bashing XML and not giving a good reason why they think it sucks?

    The only reason I think xml gets a bad rap is because of people who misuse it, like the author of today's wtf.  Don't bash something if you can't back up your opinion...


    XML is like violence: if it doesn't work, use more.

    "XML is lisp with [devil's] horns" - Brian Foote

    "XML is a giant step in no direction at all." - Erik Naggum

    Alex Papadimoulis:

    XML is designed the way it was because it was based off of HTML. Yes, that's right **XML IS BASED OFF OF HTML**.

    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

    :ul.
    :li.This is an item in an unordered list.
    To distinguish it from other items in the list, the starter set
    puts a bullet beside it.
    :p.This item consists of two paragraphs.
    This paragraph does not get a bullet
    because it is not a separate list item.
    :li.This is a separate list item
    in our unordered list.
    :eul.
    </blockote>
    Alex Papadimoulis:

    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?

    Not only is SVG an XML dialog, but it's fucked up XML on top of that...

    Simple example: SVG is a vector-based draw format. This means that most of the datum are paths. Have you ever seen how a path was specified in SVG?

    Well, you have this <path> element, and the element has an attribute called d (no, i'm not shitting you) which is an extremely explicit name for an attribute that holds path data (yep, useless attribute name because they didn't want to write "data" and went with "d" instead. Much more meaningful, probably) and the path data is a fucking space-separated list of commands and coordinates.

    Example:

    <path d="M100,100 Q200,400,300,100"/>

    <path d="M100,200 C100,100 250,100 250,200 S400,300 400,200" />

    /blockquote>

    Fucking awesome eh? I mean XML is at least supposed to be human-readable and easy to implement a parser for, but that shit? It's unreadable AND you need a specific parser to feed the path data informations to the computer after the XML's been parsed...

  • I Agree (unregistered) in reply to Xepol

    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

  • Hater (unregistered) in reply to triso
    triso:
    Rui:
    masklinn:
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?

    Nope, it's a rendering of the "Firefox Lady" by Toybox

    [image]

    Link to Toybox' post if the image doesn't work

    I thought that this rendition was awesome (while his rendition of the Xbox 360 is much less artistic) and started using it pretty much everywhere (i'm also using it as my desktop image).



    Sorry about the double post, but I just have to say this:

    That image rules !

    <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?

     

    Hmmm... let's analyze it:
    Hentai-like drawing equals nerds;
    Firefox equals nerds;

    Coincidence? No.

    Also:
    OMGWTF she has fire coming from her arse!!!

  • I Agree (unregistered) in reply to triso

    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

  • Nimrand (unregistered) in reply to Xepol

    Xepol:
    Even when you write a schema, you can EASILY write a schema that defines this XML file as legal.

    Calling XML a standard is an insult to every standard ever written before during and after the inception of XML. It is the ultimate "unstandard" standard, and it is impossible misuse, because outside of how you put the < > / characters, everything else is UP TO YOU.

    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.

  • Bleh (unregistered) in reply to Alex Papadimoulis

    Alex Papadimoulis:
    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.

    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).

  • zz plural alpha (unregistered) in reply to Hater
    Anonymous:
    triso:
    Rui:
    masklinn:
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?

    Nope, it's a rendering of the "Firefox Lady" by Toybox

    [image]

    Link to Toybox' post if the image doesn't work

    I thought that this rendition was awesome (while his rendition of the Xbox 360 is much less artistic) and started using it pretty much everywhere (i'm also using it as my desktop image).



    Sorry about the double post, but I just have to say this:

    That image rules !

    <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?

     

    Hmmm... let's analyze it:
    Hentai-like drawing equals nerds;
    Firefox equals nerds;

    Coincidence? No.

    Also:
    OMGWTF she has fire coming from her arse!!!



    And she has hair on her legs, arms and shoulders, she's secretly a dude
  • (cs) in reply to Alex Papadimoulis
    Alex Papadimoulis:

    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?



    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
  • anon (unregistered)

    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.

  • (cs) in reply to ammoQ
    ammoQ:

    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


    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!
  • (cs)

    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).

  • (cs) in reply to Bleh
    Anonymous:
    XHTML is HTML, but reformulated in XML (and some other changes) - which IS a good thing!

    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.

  • Nimrand (unregistered) in reply to masklinn
    masklinn:
    Anonymous:
    XHTML is HTML, but reformulated in XML (and some other changes) - which IS a good thing!

    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.

    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.

  • (cs) in reply to Nimrand
    Anonymous:
    masklinn:
    Anonymous:
    XHTML is HTML, but reformulated in XML (and some other changes) - which IS a good thing!

    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.

    XML doesn't have "error handling".  Its either well-formed XML, or it isn't.

    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.

    Anonymous:

    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.

    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.

  • Nimrand (unregistered) in reply to masklinn
    masklinn:
    Anonymous:
    masklinn:
    Anonymous:
    XHTML is HTML, but reformulated in XML (and some other changes) - which IS a good thing!

    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.

    XML doesn't have "error handling".  Its either well-formed XML, or it isn't.

    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.

    Anonymous:

    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.

    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.

    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.

  • (cs) in reply to Nimrand
    Anonymous:

    Nothing in the XML specification told Mozilla what to do when it recieves a mal-formed XML document

    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

    Anonymous:

    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!

    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.

    Anonymous:

    XML defines when an error has occured, not what to do about it.

    ...

    Anonymous:

    The same approach should have been taken with HTML a long time ago.

    And the web as a whole would be dead by now.

  • (cs) in reply to Nimrand
    Anonymous:

    Xepol:
    Even when you write a schema, you can EASILY write a schema that defines this XML file as legal.

    Calling XML a standard is an insult to every standard ever written before during and after the inception of XML. It is the ultimate "unstandard" standard, and it is impossible misuse, because outside of how you put the < > / characters, everything else is UP TO YOU.

    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.

    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.

  • anon (unregistered) in reply to Rui
    Rui:
    masklinn:
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?

    Nope, it's a rendering of the "Firefox Lady" by Toybox

    [image]

    Link to Toybox' post if the image doesn't work

    I thought that this rendition was awesome (while his rendition of the Xbox 360 is much less artistic) and started using it pretty much everywhere (i'm also using it as my desktop image).



    Sorry about the double post, but I just have to say this:

    That image rules !

    The image and what it says about you is disturbing on so many levels.

  • (cs) in reply to anon
    Anonymous:
    Rui:
    masklinn:
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?

    Nope, it's a rendering of the "Firefox Lady" by Toybox

    [image]

    Link to Toybox' post if the image doesn't work

    I thought that this rendition was awesome (while his rendition of the Xbox 360 is much less artistic) and started using it pretty much everywhere (i'm also using it as my desktop image).



    Sorry about the double post, but I just have to say this:

    That image rules !

    The image and what it says about you is disturbing on so many levels.

    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).

  • RobIII (unregistered) in reply to masklinn
    masklinn:
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?

    Nope, it's a rendering of the "Firefox Lady" by Toybox

    [image]

    Link to Toybox' post if the image doesn't work

    I thought that this rendition was awesome (while his rendition of the Xbox 360 is much less artistic) and started using it pretty much everywhere (i'm also using it as my desktop image).

    Damn! That is some LOOOONG butt-hair :P

    I don't date girls this hairy though....

  • Claudio Nieder (unregistered) in reply to masklinn

    <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 :-)

  • Stan (unregistered) in reply to masklinn

    Wondering if it'd look great? try along the lines of

    :ul.
    :li.This is an item in an unordered list.
    To distinguish it from other items in the list, the starter set
    puts a bullet beside it.
    :p.This item consists of two paragraphs.
    This paragraph does not get a bullet
    because it is not a separate list item.
    :li.This is a separate list item
    in our unordered list.
    :eul.
    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.
  • (cs) in reply to procyon112

    procyon112:
    It bloats data horribly.  All those end tags are just stupid.   Naming a tag again after it has already been declared is just stupid.  These stem from the unneccissary requirement that the file be "human readable".

    Yep, it should allow for an anonymous end-tag, "</>", which ends the last opening tag.

    That would be a start.

  • Bodo Eggert (unregistered) in reply to Satanicpuppy

    XML is great for what it's meant to be used for: pure data portability. You can look at a well-formed XML document, and

    ... 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.

  • dunkthegeek (unregistered) in reply to procyon112
    procyon112:

    ID of tag: 32 bits


    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

  • smurf (unregistered) in reply to procyon112

    @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.

  • (cs) in reply to Satanicpuppy
    Satanicpuppy:
    BradC:

    Sheesh. Looks like similar to a problem I'm dealing with at work. We have been parsing some fixed-width text files from a vendor that looked like:

    <font face="Courier New">Johnson   Dallas    TX    4291.3020051205
    </font><font face="Courier New"><font face="Courier New">Smith     Seattle   WA     900.0020051201
    </font><font face="Courier New">WashingtonNY        NY    1200.5020051215</font></font>

    Not too bad, but just for consistency with some of our other vendors we asked if they could send CSV file instead. Here is what we got:

    <font face="Courier New">"NAME, CITY, STATE, AMOUNT, DATE"
    </font><font face="Courier New">"""Johnson   "",""Dallas    "",""TX  "",""  4291.30"",""20051205"""
    </font><font face="Courier New"><font face="Courier New">"""Smith     "",""Seattle   "",""WA  "",""   900.00"",""20051201"""
    </font><font face="Courier New">"""Washington"",""NY        "",""NY  "",""  1200.50"",""20051215"""</font></font>

    <font face="Courier New"><font face="Times New Roman">We stuck with the original format :)</font></font>

    <font face="Courier New"><font face="Times New Roman">(Crossing my fingers that this post shows up correctly...)</font></font>



    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.



    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.


  • (cs) in reply to anon

    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

  • (cs) in reply to b1xml2
    b1xml2:
    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.

    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.

    b1xml2:
    Xml caught the imagination of software architects and middle to senior developers for what it can do to overcome today's problems.

    No, XML mostly became a buzzword (just what Ajax is currently becoming fyi) and therefore a "must-have" for any corporate pointy-head.

  • (cs) in reply to masklinn
    masklinn:
    b1xml2:
    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.

    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.

    b1xml2:
    Xml caught the imagination of software architects and middle to senior developers for what it can do to overcome today's problems.

    No, XML mostly became a buzzword (just what Ajax is currently becoming fyi) and therefore a "must-have" for any corporate pointy-head.



    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.
  • (cs) in reply to b1xml2
    b1xml2:
    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

    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?

  • foo (unregistered) in reply to Rui
    Rui:
    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

    + woman needs to shave her legs
  • Not EXEMELER (unregistered) in reply to Bodo Eggert
    Anonymous:
    >XML is great for what it's meant to be used for: pure data > portability. You can look at a well-formed XML document, > and ... 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.


    XML was developed by manufacturerers of 300 Gb Disk drives.

    </truth>
  • Cabbage (unregistered) in reply to foo

    The real WTF is all the people quoting that damned Foxy image every time they want to add a pithy remark. [pi]

  • FootFetishist (unregistered) in reply to Oliver Klozoff

    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.

  • (cs)

    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.

  • Nimrand (unregistered) in reply to nationElectric

    nationElectric:
    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.

    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).

  • Mr Uber l33t cbs gangster dude (unregistered) in reply to zz plural alpha
    Anonymous:
    Anonymous:
    triso:
    Rui:
    masklinn:
    JohnO:

    Hey Masklinn, I've always wondered...what is that a picture of?  A female pixie having sex with a planet?

    Nope, it's a rendering of the "Firefox Lady" by Toybox

    [image]

    Link to Toybox' post if the image doesn't work

    I thought that this rendition was awesome (while his rendition of the Xbox 360 is much less artistic) and started using it pretty much everywhere (i'm also using it as my desktop image).



    Sorry about the double post, but I just have to say this:

    That image rules !

    <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?



     

    Hmmm... let's analyze it:
    Hentai-like drawing equals nerds;
    Firefox equals nerds;

    Coincidence? No.

    Also:
    OMGWTF she has fire coming from her arse!!!



    And she has hair on her legs, arms and shoulders, she's secretly a dude

     

    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>.

  • (cs) in reply to Nimrand
    Anonymous:

    nationElectric:
    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.

    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).

    Personally, I keep an XML "comment" tag open at all times to include anything I say or write, like this for example.  (I'd show you what I mean, but I don't want to nest them.)  Every now and then, though, I have to close the "sarcasm" tag and open a new one, but now isn't one of those times.
  • (cs) in reply to NaNa
    Anonymous:
    Satanicpuppy:
    Heh, it's the worst XML ever.


    Nop.Every usage of XML is the worst.

    Satanicpuppy:
    The guy who wrote it clearly just didn't understand the point of XML.


    There is no point. XML deserves to die, expelled  from the civilised universe. And XML fanboys who force perfectly sane programmers to change file formats to XML should all get the clap. That fscking consultat who first forced the programmers to change their application and then sends in the result as a "WTF" should consider another career. He is definitely not fit to work as a programmer. Maybe used car sales, but not programming consultancy.


    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.


Leave a comment on “The Flat-File Society Does XML”

Log In or post as a guest

Replying to comment #:

« Return to Article