• (nodebb) 
    ?GetResultsAsJSON()
   {
        "frist_line": <![[CDATA[{"comment":"frist"}]]]>",
        "secnod_line:""<![[CDATA[{"comment":"thrid"}]]]>"
   }
  • (nodebb)

    My syntax errors were unintentional, but it's probably a better comment with them than without.

  • Maia Everett (github)

    Legacy naming can be like that. After all, in browsers, XMLHttpRequest has been mostly used to exchange JSON for many years now.

  • RLB (unregistered)

    If you think XML is even nearly dead, your programs don't communicate with banks or governments much (if at all).

  • Sauron (unregistered)

    Both XML and JSON are abominations. They should be BURNT!!!

  • (author) in reply to RLB

    My current XML nightmare is XTCE, a data interchange definition format for spacecraft. It's extremely complicated, but handles everything about how messages go from one node to another node. We're using about 25% of what the spec can do, and even that is a lot to keep track of.

  • hasseman (unregistered)

    SGML Any body?

  • see sharp (unregistered)

    Verbose and ungainly though it may be, XML still works better in certain contexts than JSON. JSON is great format for data in-transit between layers of a cohesive system. XML has benefits for data at-rest or (as it was designed to do) move data between systems that were never envisioned to work together when they were first designed.

  • LZ79LRU (unregistered) in reply to see sharp

    Indeed. Right tool for the right job and all that stuff.

  • Dr, Pepper (unregistered)

    First, Remy I'm jealous about the work you're doing -- so much more interesting than the work I'm doing. At the moment, I'm trying to fix an icon that overlays some text instead of being next to the text.

    Second, the guy who wrote this method must have been gagging at mere thought of having to write a method that pretended to return json, but returned xml instead.

  • (nodebb) in reply to see sharp

    What makes one format "better" for either of these? They're both just keys and values. XML just does it more verbosely.

    XML does have DTDs, which allow for automated validation. But there's also JSON Schemas, which I think serves a similar purpose.

  • (author) in reply to Barry Margolin

    The XML specification comes with a bunch of follow-on specifications that JSON hasn't really gotten. You want to transform a JSON document to a different schema? You're gonna have to write a program for it. In XML, you can use XSLT. Speaking of schemas, the XML schema language is a million miles better than every attempt at getting JSON schemas working. Even JSON schema implementation is nasty. When you poke into things like web services, you had federation built in- GraphQL-like queries 20 years ago.

    XML was overengineered because they were designing for the future- meeting needs nobody had at the time. JSON ended up taking off because it was just much simpler.

    Also, the semantic difference between attributes and content is a thing XML has that JSON does not, which can be informative for how we manage data- and slips beyond purely "key value" storage.

  • dusoft (unregistered)

    Remy has doubled.

  • (nodebb)

    These days, XML is (nearly) dead,

    The irony of that doesn't escape me since my primary means of interacting with The DailyWTF and many other sites is through an RSS feed.

    Also, Markdown FTW! > is your friend.

  • (nodebb)

    I wouldn't go so far to call XML dead, it's still around everywhere but no longer in the spotlight. There's some serious benefits when it comes to XML over JSON; for starters it's an solid standardized format which also has a standardized meta description format coming with it. So in other words, it's super easy to describe the format of an entity pretty easy with XML while there's no such way currently available in JSON beside a few non-standard attempts. Additionally the format enables you to add meta attributes to your data structure with, well, attributes. In JSON this is not possible and you end up with super bloated unreadable structures if you want have extendability. So yeah, XML is not dead, it's just no longer used for everything which is not a bad thing.

  • Stupid (unregistered)

    JSON loses out for the simplest of things, it does not allow comments except with a very very new parser version that nobody has. This hack is supposed to be taken serious? Bwahahaha.

  • Duke of New York (unregistered)

    Both XML and JSON are "dead" in the sense that recruiters no longer rank candidates by how many years of experience they have with either.

  • (nodebb) in reply to Remy Porter

    Remy, I've also looked at XTCE a bit, and I had trouble understanding most of it. That might be just because the terminology is different from the system that the company I work for developed internally, but we also store everything in a relational database instead of XML files, which is generally easier for me.

  • (nodebb) in reply to Stupid

    For just moving data between moderately coupled components, you don't need comments. Or whitespace, and you can quite easily avoid putting commas in the wrong places. Moreover, it's actually got a sane normalization scheme. I wouldn't recommend putting things that need to be ordinarily human readable in JSON, but it works ever so well for that ever-so-common data transfer scenario.

    When people propose using something else, they're usually talking about other scenarios. Configuration? Human-authored YAML actually does fairly well at that. Data transfer standards where you need to support all sorts of weird extensions? XML actually does pretty good there (and the alternative in that scope is something like ASN.1 DER; that's just awful, especially the whole mess that are OIDs).

  • (nodebb) in reply to dkf

    YAML is actually a horror when it comes to configuration. I can't even count the times someone mess up indention resulting in a great hunt for where it all went wrong.

    One of the benefit of XML over JSON and especially non-delimited formats like YAML is that they have start and end tags, so humna mistakes are easier to find ;-)

  • zakius (unregistered) in reply to dkf

    YAML never works, it's an abomination that should've never happen JSON5 is great for configs, though you may need to perform environment variable expansion yourself, strict requirement of the YAML spec for parsers to perform this automatically is literally the only good thing about YAML

  • zakius (unregistered) in reply to MaxiTB

    JSON actually has "closing tags" and that's why I love it

    OT: please, for the glory of everything good, do show some hint that captcha is required to submit the form BEFORE the form is populated and fails to send, it makes things so much easier

  • (nodebb)

    Ah yes, mainframe-designed XML. I remember. One element with twenty attributes, each value is a string of predefined length padded by zeroes. Just as God intended.

  • (nodebb) in reply to MaxiTB

    YAML is actually a horror when it comes to configuration.

    When it comes to configuration, I really prefer simple "key-value" systems, that organize keys by having sequences like mail.server0.protocol.

  • Officer Johnny Holzkopf (unregistered) in reply to WTFGuy

    Dem code with bugs, dem code withaht.

  • (nodebb) in reply to R3D3

    It can have some benefits (the .net options pattern deserializes tree structures like that internally and throws everything into a flat Dictionary, which has some benefits but also a lot of drawbacks when you want to bind those structure again against objects) but when you have a really complex configurations structure with dozen of branches it can become very cumbersome to read. But I personally would for sure prefer it over YAML; at least it is easier to maintain without the risk of completely breaking somehow somewhere.

  • TheCPUWizard (unregistered)

    JavaScript Serialized Object Notation...

    Are you dealing with JavaScript? NO? Then throw JSON in the trash...

    (while there has been a tiny effort to establish robust JSON with revisionable, maintainable strong schema it does not come close to predecessors like XML (all the way back to SGML or even EDIF).

    ps: Those "legacy mainframes" are still running, still having NEW code written...

  • (nodebb) in reply to R3D3
    When it comes to configuration, I really prefer simple "key-value" systems, that organize keys by having sequences like mail.server0.protocol.

    That's sort of what TOML is like, so you might want to look into it.

    My issue with YAML's indentation is because of how it represents lists and dictionaries, it's a pain to remember where exactly you need to put the dashes and exactly how much you have to indent a line.

  • (nodebb) in reply to Dragnslcr

    That's sort of what TOML is like, so you might want to look into it.

    My impression of TOML has always been "like YAML but worse".

  • Confucius (unregistered) in reply to Sauron

    Oh yeah. We need to return to the position encoded, single string of text, sent as an ftp-file transfer method of communication.

  • John (unregistered)

    Does anyone validate their XML against a DTD. Presuming that a DTD is available.

  • (nodebb) in reply to dkf

    TOML uses sections with headers like [a.b.c] instead of multiple levels of indentation. It's personal preference on which you'd rather deal with.

Leave a comment on “Get Results as What?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article