8 ms·

Maybe I am missing something, but I think thats a little extreme... If I have some data structures that I am trying to send from my C# windows app to your java

by utnick 18y ago

Maybe I am missing something, but I think thats a little extreme... If I have some data structures that I am trying to send from my C# windows app to your java unix app, how would you propose we do that? With XML, we can easily agree and collaborate on a format and both of our languages have builtin libraries to extract the data we need. Its easy to build and easy to debug.

ajross 18y ago
Yes. The fact that XML parsers are pervasive is a good thing, and an advantage for XML as a technology. But it says absolutely nothing about XML as a metadata format. A standard parser suite for anything would have the same advantages. Note also that there are other technologies with pervasively available parsers, like JSON, which don't share any of XML's warts.
dissenter 18y ago
OK, I'm going to send you a list using XML. Now how do you propose we do that? This is entirely the problem. The XML didn't solve anything. We still have to negotiate the terms of the transfer. We've agreed to use XML, true, but we are still at square one.
- olavk 18y ago
  Of course you have to negotiate the terms of the transfer. You have to do that using any format (custom binary, XML, JSON, s-expressions, whatever). XML just defines a lot of common syntactic stuff which you would have to define anyway in any format you decide on.
  - sah 18y ago
    I would argue that there's very little value in standardizing that syntactic stuff. Whatever tiny amount of value there might be is probably destroyed by picking a convention as almost universally inappropriate as XML.
- utnick 18y ago
  <list><listitem>a</listitem><listitem>b</listitem><listitem>c</listitem></list> ? The xml solved the problem of me having to write a parser from scratch for whatever terms of transfer you come up with. And I don't really see the downside for most applications.
  - BrandonM 18y ago
    So the fact that 96% of the characters you are sending are markup is not a downside? S-expressions solved this problem a long time ago. (a b c) is only 57% markup. I don't think you can get much more succinct than that and still express the idea of a list.
    - utnick 18y ago
      It is a downside, but most of the time I don't care. If I am sending some big list many times and speed really matters, then I care, but usually I am not. Size and speed are cheap nowadays.
      - BrandonM 18y ago
        It's not just about the amount of markup, though, it's about the unnecessary complexity of the markup. The software that generates and parses S-expressions is much simpler than that which generates and parses XML. Of course, in Lisp, it's just (let ((list (read data))) ...) But even in Python, you could easily hack together (not recommended) something like list = ", ".join(data.split()) ... Of course, that's not robust, but the library which is robust is much simpler than the one that requires the use of a C sax parser just to be usably fast. If the argument is that XML is more human-readable, that is implying that it's being human-modified, and then XML creates more work since it's so verbose. If the verbosity is not an issue because it's auto-generated, that implies that it's not being read/modified by humans, and the whole point of using XML in the first place is lost. I just can't see any problem that XML solves that S-expressions didn't already solve in a simpler way.
        olavk 18y ago
- trezor 18y ago
  He said: With XML, we can easily agree and collaborate on a format and both of our languages have builtin libraries to extract the data we need. You replied: OK, I'm going to send you a list using XML. The only thing you have proved here is that your blind hatred for XML makes you unable to read and parse what is posted. When arguing against the evils of a standardised format which there are proper parsers for everywhere, failing to parse stuff yourself is probably not on the list of things you want to do.
  - sah 18y ago
    You missed the point. After you've agreed on XML, you still have to agree on how to represent a list. You can use existing libraries to parse the XML, but you still have to write a parser to transform the resulting DOM into a list. Plus, given that the availability of good XML parsers is one of the primary advantages claimed for XML, can anyone name some XML parsers that aren't ridiculously slow? Maybe I haven't looked hard enough, but I always seem to find that my own code to parse ad-hoc formats goes 10x faster than, e.g., expat parsing XML.
    - trezor 18y ago
      You missed the point. After you've agreed on XML, you still have to agree on how to represent a list. No I didn't. Because that's exactly what the guy in the OP said. Agree on a XML schema for the data. After you've done that, writing some simple Xpath to get your data is done in minutes. The only times my XML code is 100% DOM is when I need to make things from scratch or do XML data manipulation.

by utnick 18y ago

ajross 18y ago

Yes. The fact that XML parsers are pervasive is a good thing, and an advantage for XML as a technology. But it says absolutely nothing about XML as a metadata format. A standard parser suite for anything would have the same advantages. Note also that there are other technologies with pervasively available parsers, like JSON, which don't share any of XML's warts.

dissenter 18y ago

OK, I'm going to send you a list using XML. Now how do you propose we do that? This is entirely the problem. The XML didn't solve anything. We still have to negotiate the terms of the transfer. We've agreed to use XML, true, but we are still at square one.

olavk 18y ago
Of course you have to negotiate the terms of the transfer. You have to do that using any format (custom binary, XML, JSON, s-expressions, whatever). XML just defines a lot of common syntactic stuff which you would have to define anyway in any format you decide on.
- sah 18y ago
  I would argue that there's very little value in standardizing that syntactic stuff. Whatever tiny amount of value there might be is probably destroyed by picking a convention as almost universally inappropriate as XML.
utnick 18y ago
<list><listitem>a</listitem><listitem>b</listitem><listitem>c</listitem></list> ? The xml solved the problem of me having to write a parser from scratch for whatever terms of transfer you come up with. And I don't really see the downside for most applications.
- BrandonM 18y ago
  So the fact that 96% of the characters you are sending are markup is not a downside? S-expressions solved this problem a long time ago. (a b c) is only 57% markup. I don't think you can get much more succinct than that and still express the idea of a list.
  - utnick 18y ago
    It is a downside, but most of the time I don't care. If I am sending some big list many times and speed really matters, then I care, but usually I am not. Size and speed are cheap nowadays.
    - BrandonM 18y ago
      It's not just about the amount of markup, though, it's about the unnecessary complexity of the markup. The software that generates and parses S-expressions is much simpler than that which generates and parses XML. Of course, in Lisp, it's just (let ((list (read data))) ...) But even in Python, you could easily hack together (not recommended) something like list = ", ".join(data.split()) ... Of course, that's not robust, but the library which is robust is much simpler than the one that requires the use of a C sax parser just to be usably fast. If the argument is that XML is more human-readable, that is implying that it's being human-modified, and then XML creates more work since it's so verbose. If the verbosity is not an issue because it's auto-generated, that implies that it's not being read/modified by humans, and the whole point of using XML in the first place is lost. I just can't see any problem that XML solves that S-expressions didn't already solve in a simpler way.
      - olavk 18y ago
trezor 18y ago
He said: With XML, we can easily agree and collaborate on a format and both of our languages have builtin libraries to extract the data we need. You replied: OK, I'm going to send you a list using XML. The only thing you have proved here is that your blind hatred for XML makes you unable to read and parse what is posted. When arguing against the evils of a standardised format which there are proper parsers for everywhere, failing to parse stuff yourself is probably not on the list of things you want to do.
- sah 18y ago
  You missed the point. After you've agreed on XML, you still have to agree on how to represent a list. You can use existing libraries to parse the XML, but you still have to write a parser to transform the resulting DOM into a list. Plus, given that the availability of good XML parsers is one of the primary advantages claimed for XML, can anyone name some XML parsers that aren't ridiculously slow? Maybe I haven't looked hard enough, but I always seem to find that my own code to parse ad-hoc formats goes 10x faster than, e.g., expat parsing XML.
  - trezor 18y ago
    You missed the point. After you've agreed on XML, you still have to agree on how to represent a list. No I didn't. Because that's exactly what the guy in the OP said. Agree on a XML schema for the data. After you've done that, writing some simple Xpath to get your data is done in minutes. The only times my XML code is 100% DOM is when I need to make things from scratch or do XML data manipulation.